【数据库集群：性能与高可用】

1.数据库集群是什么？

背景：单库困境

如果你的网站只有一个数据库，一旦用户增多就会面临两个问题：

1.性能瓶颈：所有的请求都会砸向一个数据库，同一时间数据库访问量过载，内存爆炸，CPU爆炸，读写太慢，整个系统卡死

2.单点故障：这台机器（单点）一旦因为任何原因（停电、网络断线、硬件老化、操作系统死机）挂掉，整个系统生态链上的所有业务（前端App、后端管理、客服系统）全部瘫痪，没有任何备选方案。

为了解决，引入了集群

将多台数据库服务器（节点）组合成一个整体，对外表现为一个逻辑上的单一数据库。

2.集群的三大核心模式

1.主从复制---解决读压力大

原理：一个主库（写），多个从库（读），分散压力

缺点：数据会有极短的同步延迟（毫秒级）

应用场景：内容型App（今日头条、知乎）、博客网站、企业ERP后台（内部员工查询报表多）。

2.高可用集群---解决宕机（不能停机的业务）

原理：主库“挂了”时，通过哨兵/仲裁机制自动将一个从库或备用库升级为新主库，继续提供服务。

实现了故障自动转移，应用层几乎没有感知

应用场景：所有商业系统（电商订单、OA办公、财务系统、游戏充值）。

注意：这并不是“大数据量”的方案，而是“高可靠性”的标配。哪怕只有1万用户，只要你不想半夜爬起来修服务器，就需要它。

3.分布式分片集群---解决数据量大

原理：把一张巨大的表，按某个规则（如用户ID取模）拆散，存放到多台不同的服务器上。每台只存一部分数据（分片）。

是应对亿级数据的终极方案

缺点：分片查询非常复杂，通常需要中间件支持

应用场景：国民级应用（微信支付流水、淘宝订单库、大型物联网传感器数据）。

不同数据库的对比

Nosql---Redis

Redis是内存数据库，单机内存不可能无限大（比如 256GB 到顶了）。所以它的集群核心就是 CRC16 哈希槽（Slot） 机制。

它将整个数据空间划分为 16384 个槽位，比如 3 台机器各管一部分槽（机器A管 0-5000，机器B管 5001-10000）。

关键动作：当你执行 set key1 value1，Redis 客户端会先用 CRC16 算法算 key1 属于哪个槽，然后直接跳转到对应的机器去读写。如果连错了机器，Redis 会返回 MOVED 指令告诉客户端“重定向”。这要求客户端 SDK 必须支持槽位计算。

落地级对比表