用一文建立你的分布式思维

背景

其实在写这篇文章之前，我还是个工作了4年的技术小白。4年的业务代码生涯，简便的DevOps控制台，一键傻瓜式的处理，使得我这4年除了业务经验，技术层面可以说是依托答辩。而突如其来的岗位调换，我进入到另外一个项目，开始了我的项目的前期技术调研。这就像我，一个业务代码大家，吃着火锅儿，唱着歌，突然就被麻匪劫了，但是为了生活的苟且，只能咬牙坚持了（手动狗头）。调研好久之后，哎，我又行了，又能打了（每年一次，次次挨打），于是在网上投递简历，招商的老师们觉得我简历挺不错，然后沟通能力也还可以，于是成功进入了第二轮，但是老师傅就是老师傅，一拳干碎你的技术梦

“在一个电商项目中，一个抢购商品的服务，你会怎么做？”

1.第一层的兄弟，你好

“我会使用redis缓存商品库存，并使用线程锁解决资源竞争，导致超卖问题”

我的回答很干脆，就像我的自尊一样，一击，就碎了…
这样的方案是没错，redis这个基于内存的单线程多路复用的缓存层，能快速响应服务查询并修改库存的请求，能够有效的提高我们服务的性能；那么既然是库存，那么我们应该关注到资源的竞争问题，不然不同请求处理的线程，可能会出现取到相应的库存，最终导致超卖，而这样的情况出现在生产，可能就不是超卖一件两件，一次庞大的生产事件，足以摧毁你的职业生涯，我们使用锁进行解决。

知其然
接下来我们就模拟一下问题是如何出现以及如何用代码解决这样的问题

知其所以然
问题得以解决，要不我们深入看看这些技术为什么能够解决这样的问题

2.第二层，我承认你很强

“要不再对产品抢购的微服务进行集群部署吧？这样单机的压力会小一点”

oi！小老弟不错哦，都想到集群部署了。增加业务微服务的集群，通过我们的负载均衡，通过算法使得整体流量分摊到了各个业务微服务的机器上，单机压力骤然释放。不过，既然微服务都进行集群了，redis是不是可以呐？正常的业务场景下，肯定不止一种商品在进行抢购，我们将redis进行集群部署且哨兵加主从，redis根据算法转至相应的节点进行增删查改，哎，好像我redis的压力也小了不少嘛。redis都可以集群，我mysql第一个不服，首先我们想到对单一数据库，数据库连接池是恒定不变的，那如果我将一个库分为5个，那我们就可以使用mycat这样的中间件进行分库分表，理论上我的连接池扩大了5倍，性能也随之上涨

知其然
接下来我们就模拟一下如何实现这样的方案

知其所以然

3.第三层竟如此恐怖如斯

“既然集群了，那么分布式锁与分布式事务有没有想过”

damn！damn！damn！（诺米三连音）
老师傅拳拳到肉，哥们双拳难敌四手啊！恐怖如斯！恐怖如斯啊~（手动雨中下跪）
oi！分布式锁的话，用基于redis的redssion，设置锁的时候不仅可以向各个主从节点发送锁的信息，且内部逻辑可以有效的避免死锁的发生，嘿嘿，打不着我吧。不过，分布式事务的话，某些业务可以使用弱一致性的编程形式，像是MQ这样的中间件去处理，充分解耦且可以发挥一些失败重试的机制，非常好用（反正我挺喜欢用的），而强一致性的话，就得使用一些框架来实现了，但是，这种强一致性是基于你的系统，而实际生产中，非常多的老项目，他们所使用的编程语言或是框架都不支持这样的分布式框架，所以更多的时候，对于这样的问题更多是在编程上进行差错处理，以及与其他系统的对账（不一定是帐）

知其然
那么惯例，我们来看看吧

知其所以然

4.“Fourth？me？god damn~”

“万一有人攻击你呐？成千上万个请求”

球球了别说了别说了，我招了还不行？呜呜呜!我今年26，计算机科学与技术专业，前天还在抖音看擦边，今天上午刚看的面试题…
如果硬件系统能抗住，我们的流量其实可以是无限的，但是，我的微服务扛得住吗？tomcat的线程池默认是200.当某个服务请求过多，服务一时之间忙不过来了，后面的怎么办？等待！cpu的核就这么几个，给咋都抡冒烟儿了，你那流量是嘎嘎的收，ok，哥不干了，直接罢工（宕机）。你不仅自己罢工，你还带着别人一起（关联服务因下游服务迟迟不响应而出现的宕机-服务雪崩）。

“首先对服务进行限流，当然最好是加个MQ对服务进行削峰填谷（快速响应，缓慢消费）”

既然打不过，我不打不就行咯？你流量无限多？不好意思，我只收前100，其余的都滚蛋（降级）。我们可以基于sentinel进行流量的管控，还可以针对服务进行熔断或降级，岂不美哉！流量限制了，服务的响应速度要不也再提一提？加个消息队列中间件，扔进去就了事儿，我管你成功还是失败，收钱嘛，那肯定是越多越好咯（手舞足蹈）。

知其然
那么惯例，我们来看看吧

知其所以然

从这几层之后，如果你还不清晰，那我们重新回到分布式解决了什么问题

高可用：系统能够长时间的正常运行
高性能：程序处理速度非常快，所占内存少、CPU 占用率低
高并发：在同一时间内正确处理更多的请求

还没写完，后续会把怎么做以及做的时候使用的技术的要点一点点的分析，先收藏咯，嘿嘿