05 | 系统设计目标（三）：如何让系统易于扩展？
唐扬
该思维导图由 AI 生成，仅供参考
从架构设计上来说，高可扩展性是一个设计的指标，它表示可以通过增加机器的方式来线性提高系统的处理能力，从而承担更高的流量和并发。
一般来说，基于成本考虑，在业务平稳期，我们会预留 30%～50% 的冗余以应对运营活动或者推广可能带来的峰值流量，但是当有一个突发事件发生时，流量可能瞬间提升到 2～3 倍甚至更高，我们还是以微博为例。
鹿晗和关晓彤互圈公布恋情，大家会在两个人的微博下面，或围观，或互动，微博的流量短时间内增长迅速，微博信息流也短暂出现无法刷出新的消息的情况。
那我们要如何应对突发的流量呢？架构的改造已经来不及了，最快的方式就是堆机器。不过我们需要保证，扩容了三倍的机器之后，相应的我们的系统也能支撑三倍的流量。有的人可能会产生疑问：“这不是显而易见的吗？很简单啊。”真的是这样吗？我们来看看做这件事儿难在哪儿。
为什么提升扩展性会很复杂
在上一讲中，我提到可以在单机系统中通过增加处理核心的方式，来增加系统的并行处理能力，但这个方式并不总奏效。因为当并行的任务数较多时，系统会因为争抢资源而达到性能上的拐点，系统处理能力不升反降。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了系统设计中的高可扩展性，着重讨论了通过增加机器来线性提高系统处理能力的方法。作者指出，在架构设计初期难以预测峰值流量，因此需要考虑系统的扩展性。拆分是提升系统扩展性最重要的思路，通过拆分庞杂的系统成独立的、有单一职责的模块，可以简化复杂问题。此外，文章还介绍了存储层和业务层的扩展性设计思路，包括存储层的拆分和业务层的拆分方案。通过这些设计思路，读者可以了解如何在系统设计中提升系统的扩展性，以应对突发的流量和并发。文章还提到了拆分后的系统可能带来的挑战，需要团队做好准备。最后，作者鼓励读者分享这篇文章，以便更多人受益。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《高并发系统设计 40 问》，新⼈⾸单¥59
《高并发系统设计 40 问》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(61)
- 最新
- 精选
mgxianmemcached 官方没有提供集群特性，一般第三方会使用一致性哈希算法来进行负载均衡实现集群扩展。 redis 官方的集群选择把数据根据key来哈希分配到固定数量的 slot 上，然后把 slot 再分配到具体的redis实例上来实现集群，当需要扩展时，只需要把 slot 分配一些到新加入的 redis 实例即可。这种多加一层来实现集群扩展的方式，类似于我们数据库分表时使用的索引表。作者回复: 👍👍👍👍
2019-09-27555- coffee关系型数据库是强schema约束，并且支持事务，所以扩展性相对较差。 NOSQL一般都不是强schema约束的，所以可扩展性比关系型数据库要好。
作者回复: 不只是schema free，还在于支持auto sharding
2019-09-2729 
YY数据库拆分后，但是各个库还是有相互依赖的，比如关系池，内容池都会依赖用户池，这种相互依赖的关系怎么解决？作者回复: 梳理依赖关系，如果有相互依赖的话，看看能不能拆出更基础的服务，让其他服务都依赖它
2019-12-17316- xu晓晨redis扩展主要两方面。主备方案以及集群方案。 主备的话可以用redis的sentinel（哨兵）方案主要是解决redis主节点故障后的自动切换。它负责持续监控主从节点的健康，当主节点挂掉时，自动选择一个最优的从节点切换为主节点。 集群方案的话主流的是两种 一种是codis另一种是redis官方提供的cluster。
作者回复: 👍
2019-09-30612 
A.Windy这不就是微服务嘛😄作者回复: 是的哦
2019-09-2912
hailong为了一个服务就要一个库？ 本次课程举的例子一个数据库分不同的表就行了，没懂分库啥意思作者回复: 分表的话还是不是在一个机器上，突破不了单机的限制
2019-10-0948
吃饭饭两个问题： 1）尽量不适用事务，这里是不是需要使用分布式事务？类似于使用消息中间件等？ 2）图示中的`池`指的是单个的微服务吗？我第一次听说这个概念，希望老师帮忙回答：）作者回复: 1. 其实我还没有遇到什么场景是必须要使用分布式事务的，以前做过的社区产品对一致性的要求不是很高 2. 池子指的是一组服务器组成的集群，比如用户池就是这个集群只提供用户相关的功能
2019-10-0824
helloworld系统的易扩展之从存储和业务拆分来考虑。业务拆分是容易理解的，专人专事；从存储角度来考虑我想是因为所有应用的功能的最终的结果都是把一些结果存储起来，于是存储就是重点，是重点就必然引起量大，量大了必然成瓶颈。打卡04。作者回复: 是的
2019-10-074
StarKing预测未来的数据库一定会综合ES+MONGODB的能力，直接选择库的模式就可以像NOSQL一样使用。作者回复: 这样看你团地的运维能力了
2019-10-024
飞翔老师。不太理解什么是池？ 用户池 里是一台机器还是多台机器呀？作者回复: 池子就是一组机器组成的集群
2019-09-2764
收起评论
