传统哈希算法的局限性

在分布式系统中，通常使用多个节点来保存数据，以提高并发能力和容量，那么如果决定数据保存到哪个节点上呢？一般的做法是通过一个哈希函数对数据key进行计算，然后对节点数量取模，从而得到数据分配的节点： node_id = hash(key) % N 但是这种做法在节点数量N变化的时候，大部分key的计算的节点都会重新分配。如果是应用在分布式缓存，就会导致大规模的缓存失效，引起缓存雪崩。

业务使用Redis做缓存，当有数据更新时，如何保证缓存及时更新

读数据流程

请求到来，业务代码会先查Redis，查不到再去查DB，并将结果写入Redis

写数据方案

1. 先删除缓存，再更新DB

可行性

先删除缓存，再更新DB，下次读请求到来会从数据库查到新的数据更新到缓存中。如果先更新缓存，在更新DB，更新DB失败会导致数据不一致。

为什么要限流？

由于Web服务无法控制调用方的行为，当遇到请求并发量超过系统的容量阈值，会导致服务器资源耗尽从而导致服务异常或宕机，而且某个服务的请求量突增还会影响到上游的服务，如DB或者是其他的公共服务，导致整个系统瘫痪。 可能导致流量突增的原因有以下几点：

全局唯一ID要求

分布式系统中，我们会对一些数据量大的业务进行拆分，如用户表、订单表，当数据量巨大导致数据库性能下降时，通常会进行分库分表，无法利用MySQL的自增ID，那么就需要一个单独的系统来生成全局唯一ID，而且生成的ID要求具有以下特性：

消息队列

消息队列是分布式系统的一个重要组件，从五个问题来初步认识一下消息队列，基本原理是什么样的，如何正确的使用消息队列。

• Q1: 为什么需要消息队列？
• Q2: 如何保证消息不丢失？
• Q3: 如何处理重复消息？
• Q4: 如何保证消息有序性？
• Q5: 如何处理消息堆积？

为什么需要

异步处理

• 随着业务的增长，业务逻辑会不断加重，为了保持较快速的响应，可以在核心逻辑处理完后就返回，其他逻辑放到消息队列之后异步处理

应用解耦

• 业务模块增加，可以通过订阅核心服务的消息主题，不影响核心服务

流量控制

• 后端服务无法支撑大量的并发请求，请求先放到队列，后端服务尽最大的能力消费队列

日志处理

基本概念

模型

• 点对点（队列）模型

概念

基本定义

• 微服务就是一些协同工作的小而自治的服务

服务注册与发现

• 微服务之间互相调用，服务发现需要管理各个服务的服务器地址，当进行扩容或摘除时能及时更新

服务监控

• 监控、日志、调用链、告警通知、健康检查

服务容错

• 熔断
• 切换
• 限流和降级
• 重试

服务安全

• 敏感服务进行身份验证和授权