先上图
首先说思想
思想就一个：权衡资源和业务需求
架构基本组件：
至少两台机器。【保证物理容灾】
三个mysql实例。【一主两从，一主不解释；一从主要用于实时备份，暂叫容灾从；一从用于离线计算，cache更新，非时效性的数据抓取，暂叫api从；】
ameoba 负责负载均衡和读写分离【暂时用着还可以】。
redis 负责缓存，预取，存储cache。【可以换成其他】
一个抗高并发的中间件。【暂时只加了antispam组件，高并发并未处理，可能系统负载比较平均，qpd几千万 ，但是并未出现qps峰值】
that's all，这些组件对于一个操作尚可的程序员来说，部署一整套肯定不会特别麻烦，相对于其他大型的架构来说，略显简单；但是，麻雀虽小，五脏俱全，下面从架构必备的几个角度分析一下。
安全性（Failover）
任何一个架构首要考虑的是数据安全和容灾。小拽的架构中做了哪些
数据库全量备份
这个就是一个简单脚本，对api从库在闲暇时间【晚上3-4点】进行全量导出备份，同时scp到另一台机器一份。（之所以对api库，是因为api库主要负责非失效性的查询和计算）
# crontab 每天3点进行数据库备份 (cuihuan)
# 0 3 * * * sh /home/disk6/mysql/bin/backup.sh
# 每天备份，保存最近30天的
DATE=$(date +%Y%m%d)
/home/xxx/bin/mysqldump -uroot -pxxx db > /home/xxx/bak_sql/db_$DATE.sql;
find /home/xxx/bak_sql/ -mtime +30 -name '*.sql' -exec rm -rf {} \;数据库增量备份
增量备份主要从两个角度
binlog中定期备份sql；
是采用主从库之后，从库会定时的备份主库信息，同时，对api库采用数据完全一致，对容灾库则设置只同步update 和insert；这样完备的保证了数据的安全。
可用性（Availabilty）
数据的安全排第一，毋庸置疑；次之排平台的可用性，也毫无争议。可用性最简单的一个指标则为：不卡。
cache
cache是提升查询时效性最有效的一个手段，小拽在框架中主要应用了两种cache，满足不同的业务需求。（所有关于cache的使用，一定要注意时效性和一致性，时效性和一致性，时效性和一致性）
普通的cache。即用户搜索或者查询之后的结果存在redis里面，下次查询使用。
预取的cache。即预测用户要查询的内容，放到cache里面。举几个栗子，用户首页内容一定要存cache里面；用户在看page1的时候，可以后台预测用户会看page2，提前取过来等等，这些策略和自己的实际业务紧密结合。
关于时效性和一致性再多说一句：一定要注意及时更新，例如用户写操作，点击操作，都需要在后台触发cache的主动更新，否则可能造成数据一致性错误。
分库分表
中小型的架构中，存储的瓶颈往往在于读。
随着数据的增加，读库的成本越来越大，一个sql很可能会造成锁死整个库，一条sql 10+s也是常有的事情；因此，解决读库的瓶颈，可以大大提升系统的可用性；小拽的实践中主要应用了分库，分表。
分库
之所以要分库，是因为二八原则的存在，80%的用户操作集中于20%的数据。
举个栗子：实践过程中小拽有个月库，只存本月的数据，基本上80%+的用户操作数据，都会命中这个库。
分库的原则有很多，例如时间原则，业务原则，数据逻辑原则等等；总之在您的框架中，当db扛不住的时候就分库，分层级。
分表
分表的思想和分库类似，只是粒度更小，不在赘述。
扩展性（Scabability）
小拽的架构中，扩展性主要从三个方面考虑
1：数据库的扩展性。如果资源允许N主N从都是可以的，基本上不会影响业务操作。
2：缓存的扩展。缓存基本上也是单独部署的，redis，memcache等均可以，变更成本不大。
3：高并发和负载均衡。这块属于大型网站需要考虑的，暂时只采用了ameaba进行负载均衡的扩展，高并发预留接口。
权衡（Balance）
所有的架构和技术，最终都要落实到和业务需求权衡。
上面的架构最大的优势其实就是：简单，搭建起来非常容易，这就够了。
作为一名码农，只有在实践的过程中，不断发现系统的瓶颈，权衡现有资源和需求，解决和处理问题，才能成为一名靠谱的码农。
以上只是小拽在实践过程中的一点小小心的，欢迎大家到小站交流（http://cuihuan.net）。
【转载请注明：中型存储架构实践探索 | 靠谱崔小拽 】