中型存储架构实践探索

2019年10月2日 192次阅读 来源: 崔小拽

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

先上图

《中型存储架构实践探索》

首先说思想

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

简单解释一下：对于架构的理解，个人非常认同百度架构师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）。

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

    原文作者：崔小拽
    原文地址: https://segmentfault.com/a/1190000005013177
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞