读书笔记-扩容

扩容

对于一个系统，随着产品使用的用户越来越多，网站的流量会增加，最终单台服务器无法处理那么大的流量，此时需要用分而治之的思想来解决问题。
扩容的方式：

1. 单体应用垂直扩容：直接通过增加单机硬件，如果CPU由32核升级到64核，硬盘扩展等。
2. 单体应用水平扩容：通过部署更多的镜像来实现。即负载均衡。
3. 应用拆分：讲一个大系统拆分成多个子系统，如网站系统和交易系统，而进行解耦。也可理解为SOA化，以RMI机制实现。
   另外，随着网站发展，对完站性能、可用性要求，因而在前端页面应用需要引进CDN功能，并且业务系统要支持多机房多活
4. 数据库拆分：分库分表，分库分表是一种水平拆分，会按照如ID，用户、时间等维度进行数据拆分，拆分算法可以去摸，哈希，区间等。但是，这也就导致了需要跨库join/跨表join、排序分页、自增ID、分布式事务等。对于跨库/跨表join和排序分页，可以对所有表进行扫描再聚合，或者生成全局表、进行查询维度的数据异构（比如，订单库按照查询维度异构出商家订单库、用户订单库）。
   再或者将数据同步到ES搜索。自增ID问题可以通过不同表，不同自增步长或分布式ID生成器解决。而分布式食物可以考虑事务表、补偿机制（执行回滚）、TCC模式（预占/确认/取消）、Sagas模式（拆分事务+补偿机制），业务应尽量设计为最终一致性，而不是强一致性

分库分表

1. 应用层还是中间件层。在中间件层一大好处就是对应用透明，支持多种编程语言。但是除了维护中间件外，还要考虑中间件的HA/负载均衡等。
   当当开源的Sharding-jdbc直接封装了JDBC API，所以迁移成本很低，可以对iBatis、MyBatis、Hibernate、JPA等DAO框架提供支持。
   支持分库分表、读写分离、跨库join/分页/排序等，弱事务，柔性事务（最大努力送达）。
   弱事务：由于事务不是原子的，可能提交分库1的食物，然后提交分库2的事务失败，导致跨库事务不一致
   柔性事务：当事务失败后，通过最大努力反复尝试送达操作实现，是在假定数据库操作一定可以成功的前提下进行的，保证最终一致性。
   其使用场景是幂等性操作，入根据主键删除操作，带主键插入，记录更新后状态。
   柔性食物分为同步送达和异步送达，同步送达内置在柔性事务模块中，异步送达则需要通过elastic-job实现。

分库分表策略

按照什么算法或规则进行存储，它会影响数据的写入和读取，比如按照订单ID进行分库分表，那么就很难按照客户维度进行订单查询。因此，需要慎重考虑用什么策略。

取模

可以按照数值类型主键取模来进行分库分表，也可以按照字符串主键哈希取模进行分库分表，常见的例如订单等。

• 优点：数据热点分散
• 缺点：按照非主键维度查询需要跨库跨表查询，扩容需要建立新集群，并进行数据迁移。扩容问题可以预先冗余几个表。

分区

可以按照时间分区，范围分区进行分裤分表，例如一个月一个月，一年一年等。

使用sharding-jdbc读写分离

随着数据库访问量的增长，主库不能承受更多访问，此时可以给主库挂从库，然后把读访问分流到从库减少主库压力。通过简单配置就可以讲读请求和写请求分离。

通过数据库主从分离读写，但不是从库越多越好，当从库同步遇到瓶颈，或者通过从库无法满足查询需求，应该选择数据异构。

数据异构

数据异构主要按照不同查询维度建立表结构，这样就可以按照不同维度进行查询。数据异构有查询维度异构、聚合数据异构。

任务系统扩容

需要定点执行一些任务，或者周期性执行一些任务

Elastic-job是当当开源的一款分布式任务调度框架，目前提供了两个独立子项目：Elastic-Job-Lite和Elastic-Job-Cloud。

参考

1. 亿级流量网站架构核心技术