服务幂等设计与实践

优雅停机方案

1. 非k8s，使用kill -4 进程号，让tomcat拒绝请求，再sleep 60s，等待请求处理完成。再kill 进程，再启动进程。
2. 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
• 案例三：电商平台购买商品
  • 商品价格￥10000
  • 确认收货
  • 订单状态
    • 打款
    • 修改状态
  • 分布式事务

业务层面幂等

• 冗余部署多个进程
  • 存在并发消费的可能性
  • 并发转变成串行消费
• 本质
  • 分布式锁问题

一个订单message，如果重复投递就会产生两份，那么对于一个orderId，可能有两个服务器处理，那么问题转换为分布式锁的问题。对于一个orderId只能一个处理。

分布式id生成器

twitter的snow flake雪花算法