摘要：最近一直在做平台优化对于中小型的站点，如何在资源有限的情况下，实现一个稳定，高效，靠谱的存储方案。安全性任何一个架构首要考虑的是数据安全和容灾。分库分表中小型的架构中，存储的瓶颈往往在于读。
先上图 首先说思想最近一直在做平台优化：对于中小型的站点，如何在资源有限的情况下，实现一个稳定，高效，靠谱的存储方案。下图是小拽个人在时间过程使用的一个存储架构。拿出来分享交流一下，也希望得到指点改进！
思想就一个：权衡资源和业务需求
简单解释一下：对于架构的理解，个人非常认同百度架构师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）数据的安全排第一，毋庸置疑；次之排平台的可用性，也毫无争议。可用性最简单的一个指标则为：不卡。
cachecache是提升查询时效性最有效的一个手段，小拽在框架中主要应用了两种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://www.ucloud.cn/yun/46695.html
摘要：最近一直在做平台优化对于中小型的站点，如何在资源有限的情况下，实现一个稳定，高效，靠谱的存储方案。安全性任何一个架构首要考虑的是数据安全和容灾。分库分表中小型的架构中，存储的瓶颈往往在于读。 最近一直在做平台优化：对于中小型的站点，如何在资源有限的情况下，实现一个稳定，高效，靠谱的存储方案。下图是小拽个人在时间过程使用的一个存储架构。拿出来分享交流一下，也希望得到指点改进！ 先上图 s...
摘要：近日，全新发布了软硬一体的产品与方案，宣布在中国推出系列高性能集群架构一体机，希望为用户进一步简化部署数据备份及恢复，服务更多运营与业务场景需求。本次发布的新品数据保护集群一体机是软件定义存储在备份和容灾领域的突破性实践。 作者 | 宋慧 出品 | CSDN 云计算 头图 | 付费下载于视...
摘要：本期大纲随着从到千万用户的业务增长，通过的不同服务轻松地实现高性能和高可用的基础架构。方坤老师本次的主题比较偏向实践的基础部分，假设了一个应用从小型到中型和大型的时候，可能需要用到的服务，以及相关介绍和实践建议。 极牛技术实践分享活动 极牛技术实践分享系列活动是极牛联合顶级VC、技术专家，为企业、技术人提供的一种系统的线上技术分享活动。每期不同的技术主题，和行业专家深度探讨，专注...
摘要：边缘计算是指在网络边缘节点来处理分析数据。打好边缘战，三大运营商齐头并进为了加强自身在边缘计算领域的实力，三大运营商已经开始提前布局，并取得了一定的成绩。此外，据了解，目前中国联通边缘云生态合作伙伴已达家。随着万物互联时代的到来，网络边缘设备产生的数据量飞速增长，带来了更高的数据传输带宽需求，同时，新型应用也对数据处理的实时性以及数据存储也提出了更高的要求。传统的云计算模型不能满足现有的性能...
摘要：框架篇即中间件或工具的使用，如缓存消息队列集中式日志度量微服务框架等，工欲善其事，必先利其器。 如果你正好处在中小型研发团队…… 中小型研发团队很多，而社区在中小型研发团队架构实践方面的探讨却很少。中小型研发团队特别是 50 至 200 人的研发团队，在早期的业务探索阶段，更多关注业务逻辑，快速迭代以验证商业模式，很少去关注技术架构。 这时如果继续按照原有的架构及研发模式，会出现大量的...
阅读 2523·2023-04-26 01:47
阅读 3405·2023-04-25 23:45
阅读 2075·2021-10-13 09:39
阅读 421·2021-10-09 09:44
阅读 1234·2021-10-08 10:05
阅读 1550·2021-09-22 15:59
阅读 2417·2021-09-13 10:33
阅读 1470·2021-09-03 10:30
