共计 835 个字符，预计需要花费 3 分钟才能阅读完成。
事无好坏，思维使然。
对于怎么实现承载更多用户量的零碎，是开发人员须要关注的一个技术方向。革新架构进步承载力，通常来讲分为两个大方向，互相配合实现。
硬件架构改良， 次要是应用阿里云这种多组件的云环境：通过负载平衡 SLB，模版克隆的云服务器 ECS，云数据库 RDS，共享对象存储 OSS 等不同职责的云产品组合实现。
软件架构优化， 次要是软件代码开发的标准：业务解耦合，架构微服务，单机无状态化，文件存储共享等
在分布式系统的学习途中也一直见识新的知识点，明天要说的就是软件开发时候对于接口服务的“幂等性”实现！
幂等性
成果： 系统对某接口的屡次申请，都应该返回同样的后果！（网络拜访失败的场景除外）
目标： 防止因为各种起因，反复申请导致的业务反复解决
反复申请场景案例
1，客户端第一次申请后，网络异样导致收到申请执行逻辑然而没有返回给客户端，客户端的从新发动申请
2，客户端迅速点击按钮提交，导致同一逻辑被屡次发送到服务器
简略来划分，业务逻辑无非都能够演绎为增删改查！
对于查问 ，外部不蕴含其余操作，属于只读性质的那种业务必然合乎幂等性要求的。
对于删除 ，反复做删除申请至多不会造成数据芜杂，不过也有些场景更心愿反复点击提醒的是删除胜利，而不是指标不存在的提醒。
对于新增和批改 ，这里是明天要重点关注的局部：新增，须要防止反复插入；批改，防止进行有效的反复批改；
幂等性的实现形式
实现办法： 客户端做某一申请的时候带上辨认参数标识，服务端对此标识进行辨认，反复申请则反复返回第一次的后果即可。
举个栗子： 比方增加申请的表单里，在关上增加表单页面的时候，就生成一个 AddId 标识，这个 AddId 跟着表单一起提交到后盾接口。
后盾接口依据这个 AddId，服务端就能够进行缓存标记并进行过滤，缓存值能够是 AddId 作为缓存 key，返回内容作为缓存 Value，这样即便增加按钮被屡次点下也能够辨认进去。
这个 AddId 什么时候更新呢？只有在保留胜利并且清空表单之后，才变更这个 AddId 标识，从而实现新数据的表单提交。
