中型存储架构实践探索

最近一直在作平台优化：对于中小型的站点，如何在资源有限的状况下，实现一个稳定，高效，靠谱的存储方案。下图是小拽我的在时间过程使用的一个存储架构。拿出来分享交流一下，也但愿获得指点改进！

先上图

首先说思想

思想就一个：权衡资源和业务需求

简单解释一下：对于架构的理解，我的很是认同百度架构师tandai的一句话：架构设计本质上是折衷的艺术，若是你有足够量的高速存储和高性能的机器，那么彻底能够用足量的cache，足量的离线计算存储，来提高时效性；一样，若是你的机器不足，资源不足，那么就能够经过可接受的时间消耗来节省存储空间。

架构基本组件：

• 至少两台机器。【保证物理容灾】

• 三个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）。

【转载请注明：中型存储架构实践探索 | 靠谱崔小拽 】