共计 986 个字符，预计需要花费 3 分钟才能阅读完成。
一，按业务维度拆分
比方一个零碎可能蕴含了用户，商品，订单业务，因为这三个维度在拜访与数据读写上不均衡，为防止相互影响，进步性能，能够按业务维度拆分成用户零碎，商品零碎与订单零碎。
二，数据归档
针对有的数据只须要留存而不波及到读写，能够思考将其归档。像肯定工夫前的拜访日志
三，读写拆散
对于某个零碎来说，当其倒退到肯定阶段，数据库必然会成为瓶颈，能够先思考实现读写拆散以加重对主库的压力，实现的形式大抵有两种：
- 中间件路由。在利用与数据库之间，由中间件将申请转发到读库或写库。相干的中间件有：Amoeba，MySQL-Proxy，MaxScale，MyCat 等。
- 利用外部实现路由。利用与数据库直连，由利用来定应用读库或写库。相干技术有 spring 动静数据源,Sharding-JDBC 等。
应用中间件的长处是对业务通明，不必批改代码，毛病是加长了调用链路，减少了故障点、升高了性能；而在利用外部进行路由则相同。
另外实现了读写拆散须要思考上面几个问题：
- 故障转移的问题。相干的技术有 MHA，keepalive，MyCat 等。
- 如果是应用利用进行的路由，则须要在利用里配置读写数据源。
- 主从提早的问题。针对这个问题一方面看能不能从业务上躲避，如果躲避不了则有针对性的将相干读服务连主库。另一方面如果读性能瓶颈很大，能够间接思考应用缓存代替，用缓存分片来应答数据量大的问题。
四，分表分库
数据量大到肯定水平后，数据库的读写性能会降落，更别说那些较简单的查问，个别业说单表数据达到千万级别就算是量很大，须要思考拆分存储了。就单库而言，并发达到 2000 曾经算是性能很不错了，如果再大就防止不了分库。简略一句：数据量大，就分表；并发高，就分库。
4.1 分片策略
- 范畴分片
优：减少或缩小分片时根本不波及数据迁徙，扩展性强
劣：易呈现热点数据 - HASH 分片
优：数据分布平均
劣：减少或缩小分片时波及数据迁徙，不利扩大 - 查表法
优：能够较灵便的制订映射算法，扩展性较强
劣：映射表可能成为热点表，能够思考加缓存
4.2 分片须要思考的问题
- sharding key 的抉择
如何确定分片键的时候须要依据业务来定，能够在多个维度将分片键与其它常用字段进行冗余存储。 - 分布式事务
- 分布式主键 ID
能够思考应用全局生成主键表，雪花算法等。 - 跨库 JOIN，翻页等
罕用的做法是将全量数据存入 es 或应用 hive；进行数据冗余；借助中间件；是否从业务上限度。
正文完