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

业务使用Redis做缓存，当有数据更新时，如何保证缓存及时更新 读数据流程请求到来，业务代码会先查Redis，查不到再去查DB，并将结果写入Redis 写数据方案1. 先删除缓存，再更新DB可行性先删除缓存，再更新DB，下次读请求到来会从数据库查到新的数据更新到缓存中。如果先更新缓存，在更新DB，更新DB失败会导致数据不一致。 问题容灾不足如果删除缓存失败的情况，如果业务继续进行，更新DB，...

为什么要限流？由于Web服务无法控制调用方的行为，当遇到请求并发量超过系统的容量阈值，会导致服务器资源耗尽从而导致服务异常或宕机，而且某个服务的请求量突增还会影响到上游的服务，如DB或者是其他的公共服务，导致整个系统瘫痪。可能导致流量突增的原因有以下几点： 热点业务的突发请求（如大型活动） 调用方bug导致的请求量倍增 恶意攻击的请求 为了对服务进行保护，就需要对请求进行限流。 常见算法...

全局唯一ID要求分布式系统中，我们会对一些数据量大的业务进行拆分，如用户表、订单表，当数据量巨大导致数据库性能下降时，通常会进行分库分表，无法利用MySQL的自增ID，那么就需要一个单独的系统来生成全局唯一ID，而且生成的ID要求具有以下特性： 整个系统全局唯一 ID趋势递增，提高数据库插入的效率（索引是递增的，避免乱序插入提高索引的维护成本） ID简单，占用空间小，查询效率高 常见方案...

消息队列消息队列是分布式系统的一个重要组件，从五个问题来初步认识一下消息队列，基本原理是什么样的，如何正确的使用消息队列。 Q1: 为什么需要消息队列？ Q2: 如何保证消息不丢失？ Q3: 如何处理重复消息？ Q4: 如何保证消息有序性？ Q5: 如何处理消息堆积？ 为什么需要异步处理 随着业务的增长，业务逻辑会不断加重，为了保持较快速的响应，可以在核心逻辑处理完后就返回，其他逻辑放到...

概念基本定义 微服务就是一些协同工作的小而自治的服务 服务注册与发现 微服务之间互相调用，服务发现需要管理各个服务的服务器地址，当进行扩容或摘除时能及时更新 服务监控 监控、日志、调用链、告警通知、健康检查 服务容错 熔断 切换 限流和降级 重试 服务安全 敏感服务进行身份验证和授权 HTTPS传输 隐私数据加密存储 服务治理 引入微服务框架 相比单体架构优点 技术异构性 ...

基础性能 性能指标 响应时间 吞吐量（QPS、TPS） 并发用户数：不是越高越好，如果系统来不及处理就会阻塞，响应时间会大大提高 性能优化 集群 缓存（Redis、CDN） 异步 伸缩性 扩容 无状态的应用服务器可以通过负载均衡器想集群中添加新的节点 关系型数据库可以用过Sharding实现 非关系型数据库对伸缩性支持很好 扩展性 添加新的功能对现有系统的其他应用无影响 ...