springCloud-demo集成redisson 和curator及一些思考

目录

 

整合的demo项目

对于分布式锁，redisson 和curator 一些思考

---

整合的demo项目

直接上代码

        https://github.com/smileQQQQQ/eureka-server.git

        https://github.com/smileQQQQQ/greeting-service.git

        https://github.com/smileQQQQQ/say-hello-service.git

这3个项目，分别启动eureka-server和greeting-service然后启动两个say-hello-service实例就可以demo了。

模拟并发类是concurrenceTest （ctrl+h搜一下就好了）

加锁serverice是这个testUpdateDBLock，多种方案弄的锁都在里面可以测试。

 

ps：里面有个请求“异步串行” 的方案，这是我在看别的视频中学到的思路，直接搬的代码过来，对于我来说，实在是经典。异步串行可以使同一个“方向”的请求进入到同一个线程使其保持有序，又可以通过加大线程数提高性能。

对于分布式锁，redisson 和curator 一些思考

1、redisson和curator哪个方案更好？

       使用的话，觉得差不多，这两个框架都帮处理了一些异常情况，但是查阅资料，就会知道其有很多区别。
       就原理来说，基于zookeeper（curator）实现的语义，更好理解，如果获取不到锁，只需要添加一个监听器就可以了，不用一直轮询，性能消耗较小。redis（redisson），它获取锁的方式简单粗暴，获取不到锁直接不断尝试获取锁，比较消耗性能。

       打个比方就是要使用动车厕所，redis是不断在门口转悠，等上厕所。 zk就是在座位上等着，显示器上的厕所为绿色信号亮了，知道自己可以上厕所了。

       让我选择，我还是会选择redisson，我处的大部分环境都是非极端复杂的情况，redisson是可以使用的，只要用mq这种最大限度的异步存储一些数据，如果有问题就根据这些数据进行补偿，最主要的，有redis集群，zk环境不一定有那么好的条件。   zk的创建节点，再到销毁节点通知。虽然zk就是专门干这些的，但是一旦出现问题...，比如，临时节点创建锁，业务进行到一半，挂了，这个节点没了，那么下一个节点获得通知，下一个业务开始了。当然，有团队自己根据curator framework自己定制一个，这种契合自己场景的最好了。

2、有分布式锁后，对于秒杀方案的一点想法。

     秒杀是如此火热，就算干的不是电商，也要问上一问。当然我想的时候，并不是天猫双11那种大规模的流量涌入秒杀，我想的只是十几个商品或者一个商品这种。假设一个商品1000件，实现秒杀。如果有十个分布式系统处理减库存操作，那么因为锁的存在，就是锁住这1000个商品，只有一个线程能操作，这样明显有点浪费。这个跟HashMap加上线程安全很像，其线程安全是如何实现的？ConcurrentHashMap 分段式锁，线程安全。基于这个思路，我想着1000件，可以拆成10个100，这样每个锁就管理100个库存，当然后续这个时候越想越复杂，百度一下，还真有这种思路的讲解。

https://blog.csdn.net/u010412301/article/details/89360223   

 

本次参考文章：

//Zookeeper客户端Curator Framework使用
https://blog.csdn.net/u010889616/article/details/80209629

//分布式锁选型方案，Redisson和zookeeper curator 做分布式锁的优缺点
https://www.it610.com/article/1276375951818637312.htm

//Redis 和 Zookeeper 实现分布式锁方案对比
https://blog.csdn.net/czriven/article/details/107031196

//curator 分布式锁InterProcessMutex
https://www.jianshu.com/p/5fa6a1464076