分布式系统的幂等性问题
这个应该是没有特定答案的,因情况而异,总得来说要么就是数据库层面加上唯一键,要么就是使用redis来实现幂等性
![](https://img.haomeiwen.com/i12775885/e223ab13c0b3188e.png)
分布式系统接口调用保证顺序性
![](https://img.haomeiwen.com/i12775885/b45a4712a8988998.png)
![](https://img.haomeiwen.com/i12775885/1b9a1ba36a5c7d62.png)
如果实在要求100%强顺序性,采用分布式锁方案,请求需要另外加上序号,但是这个方案会降低并发量
![](https://img.haomeiwen.com/i12775885/c2ba4fbd7b9eb3ce.png)
zk做分布式协调
![](https://img.haomeiwen.com/i12775885/fbf76e47399aaa8c.png)
zk做分布式锁
![](https://img.haomeiwen.com/i12775885/f3c252ada9c4d402.png)
zk做源数据和配置管理
![](https://img.haomeiwen.com/i12775885/aa9f4af830ffbb16.png)
zk做HA高可用性
![](https://img.haomeiwen.com/i12775885/6fc0cbfd724dbbb0.png)
redis做分布式锁的简单场景
![](https://img.haomeiwen.com/i12775885/6547ab4069f62ecc.png)
![](https://img.haomeiwen.com/i12775885/66b03cc2b82ae5fb.png)
RedLock
![](https://img.haomeiwen.com/i12775885/4c72884b8cba7d05.png)
规避单个redis宕机导致锁(用的比较少,很少验证。这个很麻烦)
集群部署的redis,使用分布式锁时有可能redis锁出现错误
redis 主从复制是异步进行的,那么就有可能在加锁的时候(master加锁成功,此时客户端会认为加锁成功,但是redis异步复制还没开始时master就已经宕机了,这个时候slave升级为master角色,但是新master并没有数据,所以下一个请求过来 又可以加锁成功了,这就形成了冲突)。要解决这个问题 的方案是加锁时,要确保主从都加锁了 客户端才认为加锁成功才行。
二者做分布式锁的对比
![](https://img.haomeiwen.com/i12775885/ca7af32a766a9d17.png)
分布式会话session
就是使用redis呗
网友评论