掘友等级
获得徽章 0
RPC安全体系
RPC通信一般为内网服务间通信，所以它的安全问题可以简化为认证授权问题、伪造注册问题。针对前者，我们可以通过授权平台管理调用方列表，申请调用权限通过后生成与其标识相对应的令牌。调用方每次调用时都需要携带这些认证参数，提供方进行Hash校验，通过才放行。而针对伪造注册隐患的解决方案是不允许多个应用同时注册服务。
集合类操作
1、需要注意构造或者切割时得到的只是原始视图，共享存储了原始对象，而不是新的对象，如果再基于视图进行增删改查很容易出现异常。比如Arrays.asList方法，再比如List的subList方法。
2、根据场景选择合适的数据结构，但是需要注意时间复杂度和空间复杂度。比如能使用HashMap进行搜索就不要使用List进行搜索，再比如LinkedList的插入效率就不如List的。
分库分表的目的是减少单表数据存储量，唯一的做法是使用主键进行分片，从而减少数据倾斜，避免热点问题。其他使用范围或者非主键进行分片都是耍流氓，拿起石头砸自己的脚。
RPC异步调用
客户调调用服务端后直接返回的不再是结果，而是CompletableFuture对象。当客户端收到服务端发送过来的响应之后，RPC框架自动地调用先前的CompletableFuture对象的complete方法，也就是将返回值注入到异步模型中，从而完成异步通知。
使用读写分离的架构下，主库更新完立即去从库读取数据，有时候会被同步延迟影响到，正常做法是避免立即去读。比如订单支付后跳到一个轻量级的支付成功页，而不是订单列表页。
任何一个存储系统，无论存储的是什么数据，用的什么样的数据结构，都可以抽象成一个状态机，因此我们可以基于它的快照进行备份、恢复、复制。
路由分组
稳定性保障中很重要的一点就是自适应保护，比如通过隔离失败保证提供给核心服务的接口可用，更具体的落地方案有路由分组，不同级别的系统调用不同的分组，从而达到隔离的目的。不过对于服务使用者来说，可调用的列表减少了，这种情况下RPC框架最好提供主、备分组的逻辑，当主分组全部不可用后，再使用备分组。
策略模式
通过查表法动态获取对应的策略，而不是通过冗长的if-else条件判断。很显然，这种模式解藕了策略的定义、创建、使用，有效控制了代码的复杂度，让每个部分都不至于过于复杂、代码量过多。
CAP三角型理论
在不能容忍分区P异常时,数据强一致性C和服务总是可用A之间只能有一个，也就是要么是CP要么就是AP。比如说读取数据时发生了网络超时或者请求阻塞，无法及时响应，此时要保证服务的可用性，只能返回不是最新的数据。当然CA组合也是有的，比如单机版本的数据库系统。
