登录
首页 >  数据库 >  MySQL

中型存储架构实践探索

来源:SegmentFault

时间:2023-02-21 19:42:54 203浏览 收藏

来到golang学习网的大家,相信都是编程学习爱好者,希望在这里学习数据库相关编程知识。下面本篇文章就来带大家聊聊《中型存储架构实践探索》,介绍一下MySQL、Redis、读写分离、主从备份,希望对大家的知识积累有所帮助,助力实战开发!

最近一直在做平台优化:对于中小型的站点,

如何在资源有限的情况下,实现一个稳定,高效,靠谱的存储方案
。下图是小拽个人在时间过程使用的一个存储架构。拿出来分享交流一下,也希望得到指点改进!

先上图

存储架构

首先说思想

思想就一个:

权衡资源和业务需求

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

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

今天关于《中型存储架构实践探索》的内容就介绍到这里了,是不是学起来一目了然!想要了解更多关于mysql的内容请关注golang学习网公众号!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表