shrek的博客

1.redis string 常见的应用场景 计数功能，incr get 各类场景下（单机或者分布式）的标识号 集群环境下的session共享 使用spring session 和redis完成session共享2.string 实现分布式锁 锁的场景，多任务环境下，多对一 有状态的资源-会不一样的（有状态的）1+1+1=33.锁的实现是通过setnx 来实现的4.redis加锁的正确的姿势，通过setnx向特定的key写入一个随机值，并同时设置失效时间，写值成功及加锁成功...

Seata sage模式1.主要是通过状态机，流程去执行，状态机说白了，就是工作流，主要配置json文件，代码往下执行 也存在TCC模式中的问题，空回滚，悬挂问题，幂等性问题2.seata 3中模式的对比 AT模式，效率不高，事务的实时性比价好，使用比较简单，兼容所有的基于jdbc规范 的orm框架,RM是使用dataSourceProxy来做处理的 TCC模式，RM不需要代理数据源，跟TC通讯，注册分支事务，调用try方法 try接口主要做的事情，冻结资源，不是真正的去操作目...

Seata 后续：1.TCC模式，t-try prepare c-confirm c-cancel,2.除了TM 上面的@GloadTansational,注解外，各个的RM的接口上面要有@TwoPhaseBusinessAction(name=,commitMethod=, rollbackMethod=)3.如果t,出现问题，则回滚执行rollback方法，如果c,出现问题了，就不回滚4.T-papare-尝试去做，不真正的操作业务sql，或者业务字段，第一阶段的try，只是对目标字段的尝..

1.预生成订单id，订单信息存到redis中，订单id 返回给前端。提到吞吐量。2.消费到死信队列中的消息话，lua脚本库存+13.微信支付有预支付，先生成二维码，然后扫码支付。4.延迟队列->死信队列里面的消息是必须消费的，消费的时候去判断状态，未支付的话 库存+1。支付的话，不做什么操作。5.支付的话，微信是会有一个回调的，回调是会调用我们自己的系统的，去修改支付状态， 库存去真正的减1，同时还会去增加积分，发物流等等，这点涉及分布式事务的操作6.当微信回调的时候，有可能超时，...

先来个题外话~servlet 3.0规范1.其实提高并发请求，就是减少tomcat线程池中，线程的执行时间，说白了就是提高利用率。而servlet 3.0就是，一个用户请求过来了，访问servlet拿到一个线程之后去处理了业务逻辑，这时候业务逻辑块开启了 一个新的线程去处理自己的业务逻辑，处理完之后，在此调用 servlet.虽说次数增多了，但是两次时间都是比较短，整体的并发量也就上去了。rabbitMQ 下订单1.有两种模式，一种是推，一种是拉，默认是推，拉是，消息执行完主动去拉，...

扯扯犊子并发知识点总结：1.秒杀，物理业务隔离，抽成单独的服务器2.接口设计，防止洪流访问数据库。3.加redis缓存。4.缓存雪崩，一个请求，多个key同时失效，避免同时失效。多个请求，一个key失效。加锁5.热点数据，缓存预热。6.超过10w+的时候，增加本地缓存ehchache，redis作为二级缓存7.缓存，ehcache,现在有了大堆得概念，毕竟是本地缓存，减少io，加快速度扣减库存逻辑，你值得拥有~1.基于DB做数据库的扣减库存2.基于redis扣减库存 incr.