一致性哈希

对节点和key进行hash计算，分布在2^32槽的环上。
对于节点比较少的，虚拟节点防止数据倾斜。

性能标准

吞吐量，qps（每秒处理请求数），tps（每秒处理事务数）。
rt（请求延迟）。
95线99线就是95%，99%。并发100，可以达到80ms延迟，过95线。

id生成方案

id uuuid(32字节)
雪花(8字节 时间相关)
时钟回拨问题，发现重复阻塞5ms重试。
或者预留的值累加避免重复，如果累加到一定程度抛异常。

分布式事务

2pc，3pc是数据库层面的，而tcc是业务层面的。

• 2pc
  协调者，参与者。
  第一步，协调者会发送给参与者事务请求，参与者进行预处理，记录undo，redo日志。
  第二步，协调者接到全部的返回，通知所有参与者进行统一操作。

• 3pc
  与2pc类似，把第一步分为两步，保证参与者执行提交或者回滚任务，状态是一致的。另外协调者和参与者都加了超时检测机制，如果协调者发生故障，参与者可以在超时过后，执行提交。如果参与者发生故障，协调者收不到参与者的返回，可以继续进行统一回滚。2pc这两种情况，都会占用资源，阻塞各参与者的处理。

• tcc（Try Confirm Cancel）事务补偿
  大致分3步，先try一下，根据try的结果，确定走confirm或者cancel。
  Try 阶段去占库存，Confirm 阶段则实际扣库存，如果库存扣减失败 Cancel 阶段进行回滚，释放库存。
  TCC 不存在资源阻塞的问题，因为每个方法都直接进行事务的提交，一旦出现异常通过则 Cancel 来进行回滚补偿，这也就是常说的补偿性事务。
  通常会利用事务表来记录事务提交情况，避免空回滚，悬挂，幂等问题。
  空回滚，try超时了执行cancel时，应该不走业务，直接return。
  在try是插入事务记录，cancel时发现事务记录没有，就插入事务记录（避免悬挂问题），return；
  悬挂，try超时了执行cancel，之后try又执行，如果再try方法里执行了记录锁定，可能就释放不了锁了。在执行try之前先检查是否已经有事务记录了，如果已经存在就不执行try。
  幂等，执行前先检查下是否已经存在事务记录。

• mq
  保证节点事务和消息原子操作，发给下游，下游也同样，执行任务返回消息。

• sega
  事务1，事务2，事务3
  事务1回滚操作，事务2回滚操作，事务3回滚操作
  按个执行事务，失败就执行对应的回滚操作。