架构设计-读写分离、分库、缓存

性能问题

• 容量问题：如负载再继续增加则服务器无法负担，如果不加限流可能导致服务器超负荷而死机。
• 时延问题：请求时延、请求响应时间长。

数据库读写分离

一个主库承担写操作，多个从库承担只读操作，主库和从库之间通过数据复制技术同步数据。

解决问题

主要解决单数据库读性能瓶颈问题（负载能力）。一个数据库同时承担写和读，负载超出服务器处理能力。通过写读分离及多个读库分担数据库的压力。
尤其适合写少、读多的场景，如写:读比例大于1:10。

• 线性提升数据库的读性能；
• 消除读写锁冲突提升数据库写性能；

难点

• 数据同步技术、数据一致性＆数据同步实时性。
• 数据库连接池要区分。

缓存

指将全部或部分数据加载到缓存，当所查找数据可以从缓存获取时直接查缓存，缓存未命中时再读数据库。

解决问题

主要解决数据查询速度、及数据库压力问题。缓存查询速度通常是数据库查询速度的几十、上百、上千（本地缓存）倍。同时由于大量读流量被缓存分担，也间接降低了数据库负载。

难点

• 高可用问题：如缓存挂了，数据库容易瞬间被压垮。
• 缓存刷新、数据一致性问题：需要设计保证当数据更新后，缓存数据及时进行刷新。
  • 对长期有效的缓存数据，可以基于消息队列，当数据做了更新后发布更新消息，缓存刷新进程订阅消息 ，执行缓存刷新。可以只置相应数据缓存过期，由缓存读操作中封装数据刷新逻辑；或加锁主动刷新缓存。
  • 对只某段时间内有效的数据，可以在数据缓存时即设置失效周期，过期及被清理（依赖缓存框架的能力），如客户资料。（采用同样的数据刷新机制，可以更新时判断是否已缓存，已缓存则异步服务调用置缓存失效）

水平分库

指按某种规则，将一类超大容量数据水平切分，均匀分布到多个数据库，其中每一份数据为一个分片。
注：将不同类型（领域）的数据分离到不同数据库的方式称为垂直分库。

解决问题

解决单数据库处理容量问题，使得系统可以支持更大容量。（垂直分库+水平分库）

难点

• 事务问题，如果数据切分粒度设计不好，可能导致跨库的分布式事务问题。也会极大增加逻辑实现的复杂性，如一笔业务涉及多库操作。（通常依赖DDS，支持SQL拆分、及XA）（业务设计尽可能规避跨库操作）
• 跨库查询问题，导致查询逻辑实现复杂、或性能变差。如关联查询、排序、分组。（通常依赖DDS，支持SQL拆分、数据聚合处理）

总结

1. 如果是数据库容量问题，通常采用分库设计解决，先垂直分库、再水平分库。
2. 如果是数据库性能问题（通常指单库），首先优先使用缓存手段，如果使用了缓存后仍然存在性能问题，则再考虑使用读写分离设计。