服务幂等设计与实践
优雅停机方案
- 非k8s,使用kill -4 进程号,让tomcat拒绝请求,再sleep 60s,等待请求处理完成。再kill 进程,再启动进程。
- k8s,利用k8s的机制,使用iptable 限制入口,sleep60s,kill 进程,kill pod。
修改linux系统的连接数fd的限制
ulimit -n fd
幂等定义
- 请求层面
- 保证请求重复执行和执行一次结果相同
- f…ff(x)=f(x)
- x是参数
- f是执行函数/方法
- 业务层面
- 同一用户不重复下单
- 商品不超卖
- MQ消费端去重
幂等目的
- 请求重试
- 某银行幂等案例
- 结果灾难性
- 转账
- 交易
银行的服务器不做重试,由客户端来进行重试。
幂等范围
对数据有改变请求才需要做幂等
什么请求要做幂等?
写请求要做幂等。
哪些层需要做幂等?
反向代理层?网关层?业务层?数据访问层?
数据访问层
- CRUD的幂等性
- C:如果使用的是业务主键就不会产生幂等性问题
- R:没有对数据改变
- U:类似例子1的绝对值的update是幂等的。但是类似例子2的相对值的 34+update是不幂等的。
- D:类似例子1的delete是幂等的。但是类似例子2的delete是不幂等的。 但是类似例子2的案例在实际情况中很少,忽略
update幂等案例
- 案例一:QQ离线消息读取
- 天然幂等
- 案例二:年龄增加1岁
- 增加where条件
- where age = 18
- 相对修改换成绝对修改
- set age = 19
- 增加where条件
- 案例三:电商平台购买商品
- 商品价格¥10000
- 确认收货
- 订单状态
- 打款
- 修改状态
- 分布式事务
业务层面幂等
- 冗余部署多个进程
- 存在并发消费的可能性
- 并发转变成串行消费
- 本质
- 分布式锁问题
一个订单message,如果重复投递就会产生两份,那么对于一个orderId,可能有两个服务器处理,那么问题转换为分布式锁的问题。对于一个orderId只能一个处理。
分布式id生成器
twitter的snow flake雪花算法