浅谈几种常用负载均衡架构

随机方式：请求随机分布到各个结点;在数据足够大的场景能达到一个均衡分布;

• 优点：实现简单、易水平扩展
• 缺点：同 Round Robin，无法用于有写的场景
• 应用场景：数据库负载均衡，也是只有读的场景

哈希方式：根据 key 来计算需要落在的结点上，可以保证一个同一个键一定落在相同的服务器上;

• 优点：相同 key 一定落在同一个结点上，这样就可用于有写有读的缓存场景
• 缺点：在某个结点故障后，会导致哈希键重新分布，造成命中率大幅度下降
• 解决：一致性哈希 or 使用 keepalived 保证任何一个结点的高可用性，故障后会有其它结点顶上来
• 应用场景：缓存，有读有写

一致性哈希：在服务器一个结点出现故障时，受影响的只有这个结点上的 key，最大程度的保证命中率;如 twemproxy 中的 ketama方案;生产实现中还可以规划指定子 key 哈希，从而保证局部相似特征的键能分布在同一个服务器上;

• 优点：结点故障后命中率下降有限
• 应用场景：缓存

根据键的范围来负载：根据键的范围来负载，前 1 亿个键都存放到第一个服务器，1~2 亿在第二个结点。

• 优点：水平扩展容易，存储不够用时，加服务器存放后续新增数据
• 缺点：负载不均;数据库的分布不均衡;
• (数据有冷热区分，一般最近注册的用户更加活跃，这样造成后续的服务器非常繁忙，而前期的结点空闲很多)
• 适用场景：数据库分片负载均衡

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!