无状态设计如何诞生
后台开发可能都经历过下面这种架构，尤其在初创公司或小规模公司内经常这样设计，产品往往做前后端分离，服务MVC架构
其缺点：单点问题，服务宕机整个服务不能用；用户体验，一个服务提供，大量请求无法快速响应
随着公司的成长，用户增加，这种架构的缺点暴露无遗，此时单个服务承载能力受限制，用户无法得到好的体验，此时怎么办？往往做法是Nginx后面再挂一台机器，部署同样的服务，也就是做了冗余
降低响应延时，提升用户体验
服务自由冗余，依据业务规模快速扩容和缩容
同一服务冗余部署N个，比如3个，那么客户端访问服务时，若参数相同，请求api相同(同一个服务）时，无论是否是同一个客户端，还是不同时间点都应该返回一致的结果，此时我们就说服务满足无状态设计。
无状态手段
把有状态的数据从服务分离出来，单独存储，比如存到公共缓存、比如放到客户端
A：DB 存储 B：APP 存储
C：服务存储 D：cache 存储
案例-2
同一个请求重复执行和执行一次的所产生的影响一致，比如，银行转账，用户A向用户B赚100元，网络抖动或故障或服务故障，导致某个环节重试，但无论怎样，都要保证最终用户A只向用户B转账100元，而不是其它金额。
请求幂等解决的问题
幂等是要保证数据和用户或业务的预期一致，数据在哪儿？在数据库。谁会改变数据库？CRUD操作会改变数据，因此幂等本质变成了CRUD要幂等。因此判定那块需要幂等，就看谁在操作CRUD，在微服务中就是DAS（数据访问服务）了
自增主键：app发起请求存储用户数据，第一次走①的流程，由于app请求超时，app重试，发起第二次请求，第二次按照②的路径，最终导致数据库张三的用户重复插入两条，所以自增主键的 Create 操作不幂等
自增主键+唯一索引：假设上图中，设置name为唯一索引，那么②的路径就会执行失败，所以幂等
业务主键：数据库不采用自增主键，然后客户端在操作时首先获取一个主键，然后带上主键去请求，这样能保证幂等。主键一定是客户端获取，其它地方都会造成重试，重新生成主键可能还是不幂等 
读操作不改变数据，天然幂等
Update操作幂等吗
Delete操作幂等吗
delete操作，一般的删除幂等，删一次和删除两次都一样，但是类似带上limit这样的删除不幂等，会多删除数据，但是这种业务中很少用。
