猫猫头

Broker端则会针对每个\维护一个序列号（SN），只有当对应的SequenceNumber = SN+1时，Broker才会接收消息，同时将SN更新为SN+1。通过预分配ID就容易避免，客户端每次提交订单都需要携带一个提前获取的订单id，当服务端检查有重复的订单id时，就可以拒绝。如果改为提前分配好ID， 客户端将ID与数据一同发送给服务端，服务端进行ID验证，检查这个ID是否已经处理过了。这个PID对用户是不可见的。这么做的后果是客户端每次提交都会得到一个新的ID，即使客户端提交了重复的数据。

注册中心推送的实例列表为空，节点如果替换了本地缓存列表，那就会无实例可用no provider，注册中心推空，很可能是网络问题导致的， 所以节点不能完全信任注册中心，当注册中心推空时，忽略本次推送，尝试继续通过本地缓存访问实例列表，如果访问失败，再做健康检查。业务方依赖一个接口sdk，主要逻辑全部写在agent包中，在部署时，只需要加载agent即可，中间件升级时，替换agent，而不用频繁更新sdk。存活探针，探测容器是否真的存活，有问题则重启容器，防止容器进程存活，但已经无法对外服务，死锁等。

离线数据库迁移简单的原因是在数据库做切换的时候，系统是离线的，也就不会有新数据写入，此时进行数据库切换，不会有数据一致性的问题。企业级项目还可以在半夜停机同步，但如果数据量非常大，一晚上的时间可能也不够，还是需要做好随时回滚，双库随意切换以保障数据安全。然后离线进行数据库切换，只需要短暂的停机，就可以实现切换。回滚操作：由于一直保留着旧库，并做了新库同步到旧库，所以旧库的数据依然是完整的，可以随时切换回旧库。canal数据同步，停掉binlog同步，改为数据补偿， 如新库写入失败的， 需要补偿程序弥补。

分布式唯一ID是在分布式系统中生成全局唯一标识符的解决方案，用于确保不同节点产生的ID不重复

在客户端请求的header中增加一个标识， 标识为灰度版本的请求， 在网关路由中，如果检测到灰度标识， 就将该请求转发到拥有同样灰度标志的服务。客户端向注册中心拉取实例时，注册中心要提供标记筛选接口，或是返回实例列表时，同时携带标记，让客户端自己筛选。给服务实例打上版本或灰度标记，网关入口或上游服务访问下游服务时，可以依据服务标记选择合适的服务实例。类似链路追踪组件，请求要从前端或网关开始，携带标记条件，在所有服务路径中都要保持。客户端负载均衡或服务端负载均衡器，要根据请求标记， 匹配实例列表的标记。

若给节点增加从节点，从而提高可用性， 但主从同步时仍然可能出现不一致的情况， 如主加锁成功，但在同步前宕机， 从节点变为主，没有锁。锁续命：在获得锁后， 增加一个定时任务，定期检测任务线程是否已执行完成，若未完成，则延长锁的过期时间。解决：加锁时候，value添加唯一标识（uuid）， 解锁的时候判断是否是自己加的锁，然后删除锁。问题2：在删除锁逻辑中， 判断是否自己锁和删锁并非原子操作，还是会出现超时后删别人锁的情况。当为了性能，节点部署不多时，节点宕机容易造成半数锁失败，红锁 red lock。

5、在update操作时，需要更新数据库，更新缓存两个操作，这两个操作是非原子性的，在两个操作之间，数据库与缓存数据是不一致的，此时的不一致时间还不是很长。--------双写不一致。3、若管理端删除了某个数据，前端还停留在被删数据页面，此时前端请求了已经不存在的数据，缓存查找没有，会访问数据库，前端若一直请求，会持续对数据库造成压力。4、若大量并发瞬间访问了一个冷门数据（无缓存的），请求发现无缓存，会进行缓存重建，大量请求进行缓存重建，对数据库压力较大。------------缓存重建。