shining曙光的博客

https://segmentfault.com/a/1190000022740402

一、本地事务1、隔离级别2、传播属性require同生共死。所有事务设置都用a的require_new 可以单独控制但是在同一个service里，c设置了new事务也没用，因为springboot里的事务是通过代理实现的，这样做绕过了代理。解决：二、分布式事务1、原因分布式系统间各种问题：宕机、网络不稳定本地事务无法满足需求：1）远程服务假失败： 远程服务其实成功了，由于网络故障等没有返回 导致：订单回滚，库存却扣减2）远程服务执行完成，下面的其他方法出现问题 导致：已执行的远程

1、双写模式最终一致性，适合场景：可以容忍一段时间的脏数据。2、失效模式3、解决方案• 1、如果是用户纬度数据（订单数据、用户数据），这种并发几率非常小，不用考虑这个问题，缓存数据加上过期时间，每隔一段时间触发读的主动更新即可• 2、如果是菜单，商品介绍等基础数据，也可以去使用canal订阅binlog的方式。• 3、缓存数据+过期时间也足够解决大部分业务对于缓存的要求。• 4、通过加锁保证并发读写，写写的时候按顺序排好队。读读无所谓。所以适合使用读写锁。（业务不关心 脏数据，允许临时脏数

1、目标高可用（High Availability），是当一台服务器停止服务后，对于业务及用户毫无影 响。 停止服务的原因可能由于网卡、路由器、机房、CPU负载过高、内存溢出、自 然灾害等不可预期的原因导致，在很多时候也称单点问题。• 突破数据量限制，一台服务器不能储存大量数据，需要多台分担，每个存储一部分， 共同存储完整个集群数据。最好能做到互相备份，即使单节点故障，也能在其他节点 找到数据。• 数据备份容灾，单点故障后，存储的数据仍然可以在别的地方拉起。• 压力分担，由于多个服务器都能完成各自一

分布式锁要求：互斥、防止死锁、重入、性能1）数据库实现缺点：1.db操作性能较差，并且有锁表的风险2.非阻塞操作失败后，需要轮询，占用cpu资源;3.长时间不commit或者长时间轮询，可能会占用较多连接资源2）Redis(缓存)实现缺点：1.锁删除失败 过期时间不好控制2.非阻塞，操作失败后，需要轮询，占用cpu资源;3）ZK实现缺点：性能不如redis实现，主要原因是写操作（获取锁释放锁）都需要在Leader上执行，然后同步到follower。优点：较好的性能和可靠性。从理解

一、计数器从第一个请求进来开始计时，在接下去的1s内，每来一个请求，就把计数加1，如果累加的数字达到了100，那么后续的请求就会被全部拒绝。等到1s结束后，把计数恢复成0，重新开始计数.可使用redis的incr原子自增性和线程安全即可轻松实现。如果我在单位时间1ms内的前10ms，已经通过了100个请求，那后面的990ms，请求全部会被拒绝，即：突刺现象。二、滑动窗口算法滑动窗口算法是将时间周期分为N个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期,滑动窗口的格子划分的越多

一、UUID：UID使用以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字来生成一串唯一随机32位长度数据。优点：性能好，本地生成，全局唯一。缺点：UUID长度固定为32位，对于Mysql索引来说，所有的非主键索引都会包含一个主键，UUID长度过长会不利于MySql的存储和性能。UUID是乱序的，每一次UUID数据的插入都会对主键地城的b+树进行很大的修改。信息不安全，UUID里包含了MAC地址，芯片ID码能信息。会造成信息泄露。二、数据库自增ID对于多台数据库，通过每台数据库的起始值

1）中间件的网络io耗时很多，优化措施更好的网线、带宽、网络设备更好的网络协议2）业务代码耗时更长db3）静态资源获取–nginx动静分离

转载 https://www.fangzhipeng.com/springcloud/2019/08/21/distributed-logs.html背景开发排查系统问题用得最多的手段就是查看系统日志，在分布式环境中一般使用ELK来统一收集日志，但是在并发大时使用日志定位问题还是比较麻烦，由于大量的其他用户/其他线程的日志也一起输出穿行其中导致很难筛选出指定请求的全部相关日志，以及下游线程/服务对应的日志。解决思路每个请求都使用一个唯一标识来追踪全部的链路显示在日志中，并且不修改原有的打印方式(代码