读写分离基本原理

读写分离的基本原理是：主服务器用来处理写操作以及实时性要求比较高的读操作，而从服务器用来处理读操作。

1. 为何要读写分离

• 有效减少锁竞争 - 主服务器只负责写，从服务器只负责读，能够有效的避免由数据更新导致的行锁竞争，使得整个系统的查询性能得到极大的改善。
• 提高查询吞吐量 - 通过一主多从的配置方式，可以将查询请求均匀的分散到多个数据副本，能够进一步的提升系统的处理能力。
• 提升数据库可用性 - 使用多主多从的方式，不但能够提升系统的吞吐量，还能够提升数据库的可用性，可以达到在任何一个数据库宕机，甚至磁盘物理损坏的情况下仍然不影响系统的正常运行。

分库分表基本原理

1. 为何要分库分表

分库分表主要基于以下理由：

• 并发连接 - 单库超过每秒 2000 个并发时，而一个健康的单库最好保持在每秒 1000 个并发左右，不要太大。
• 磁盘容量 - 磁盘容量占满，会导致服务器不可用。
• SQL 性能 - 单表数据量过大，会导致 SQL 执行效率低下。一般，单表超过 1000 万条数据，就可以考虑分表了。

#	分库分表前	分库分表后
并发支撑情况	MySQL 单机部署，扛不住高并发	MySQL 从单机到多机，能承受的并发增加了多倍
磁盘使用情况	MySQL 单机磁盘容量几乎撑满	拆分为多个库，数据库服务器磁盘使用率大大降低
SQL 执行性能	单表数据量太大，SQL 越跑越慢	单表数据量减少，SQL 执行效率明显提升

分布式 ID 基本原理

传统数据库软件开发中，主键自动生成技术是基本需求。而各个数据库对于该需求也提供了相应的支持，比如 MySQL 的自增键，Oracle 的自增序列等。

数据分片后，不同数据节点生成全局唯一主键是非常棘手的问题。同一个逻辑表内的不同实际表之间的自增键由于无法互相感知而产生重复主键。 虽然可通过约束自增主键初始值和步长的方式避免碰撞，但需引入额外的运维规则，使解决方案缺乏完整性和可扩展性。

为此，需要使用分布式 ID 来解决此问题。本文总结业界常用的分布式 ID 解决方案。

缓存基本原理

缓存是一种利用空间换时间的设计，其目标就是更快、更近。

缓存简介

为什么需要缓存

众所周知，当今是一个互联网时代，而互联网应用几乎遍及我们日常生活的方方面面。一般而言，一个互联网应用的请求/响应流程会有以下几个主要流程：

• 客户端发起请求，请求经过网络 I/O，分发到服务层。
• 服务层可能有多级服务，请求需要被多个服务层层处理。
• 不同服务根据请求进行计算时，可能依赖于不同数据库的数据，需要通过网络 I/O 读写数据库。