这是别人说的，咱也不敢说，咱也不敢问 ! 了解大致的逻辑就好.你只需要知道他超级牛逼,超级方便
安装就是简单的 pip install ray , 需要提醒的就是ray现在只有linux编译版本, windows就别想着用了,为了这,我硬生生把开发环境从windows切到了linux.
首先来看一下最简单的Ray程序是如何编写的。
在Ray里，通过Python注解@ray.remote定义remote函数。使用此注解声明的函数都会自带一个默认的方法remote，通过此方法发起的函数调用都是以提交分布式任务的方式异步执行的，函数的返回值是一个对象id，使用ray.get内置操作可以同步获取该id对应的对象
参考:
高性能分布式执行框架——Ray
取代 Python 多进程！伯克利开源分布式框架 Ray
官方文档
基于python的高性能实时并行机器学习框架之Ray介绍
主要用于分散压力，所以分布式的服务都是部署在不同的服务器上的，再将服务做集群
根据“分层”的思想进行拆分。
例如，可以将一个项目根据“三层架构” 拆分
然后再分开部署 ：
根据业务进行拆分。
例如，可以根据业务逻辑，将“电商项目”拆分成 “订单项目”、“用户项目”和“秒杀项目” 。显然这三个拆分后的项目，仍然可以作为独立的项目使用。像这种拆分的方法，就成为垂直拆分
主要用于分散能力，主要是将服务的颗粒度尽量细化，且自成一脉，压力这块并不是其关注的点，所以多个微服务是可以部署在同一台服务器上的
微服务可以理解为一种 非常细粒度的垂直拆分 。例如，以上“订单项目”本来就是垂直拆分后的子项目，但实际上“订单项目”还能进一步拆分为“购物项目”、“结算项目”和“售后项目”，如图
现在看图中的“订单项目”，它完全可以作为一个分布式项目的组成元素，但就不适合作为微服务的组成元素了（因为它还能再拆，而微服务应该是不能再拆的“微小”服务，类似于“原子性”）
分布式服务需要提供给别的分布式服务去调用，单独拆出来 未必外部可用
微服务自成一脉，可以系统内部调用，也可以单独提供服务
为什么需要用分布式锁，见下图
变量A存在三个服务器内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果不加任何控制的话，变量A同时都会在分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的！即使不是同时发过来，三个请求分别操作三个不同内存区域的数据，变量A之间不存在共享，也不具有可见性，处理的结果也是不对的。
分布式锁应该具备哪些条件：
1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
2、高可用的获取锁与释放锁；
3、高性能的获取锁与释放锁；
4、具备可重入特性；
5、具备锁失效机制，防止死锁；
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败
Redis性能高
命令简单，实现方便
使用setnx加锁，key为锁名，value随意不重复就行（一般用uuid）
给锁添加expire时间，超过该时间redis过期（即自动释放锁）
设置获取锁的超时时间，若超过时间，则放弃获取锁
通过锁名获取锁值
比较锁值和当前uuid是否一致，一致则释放锁（通过delete命令删除redis键值对）
2PC：two phase commit protocol，二阶段提交协议，是一种强一致性设计。
同步阻塞（导致长久的资源锁定） ，只有第一阶段全部正常完成（返回失败，回字返回超时都会返回 “准备失败” ），才会进入第二阶段
因为协调者可能会在任意一个时间点（发送准备命令之前，发送准备命令之后，发送回滚事务命令之前，发送回滚事务命令之后，发送提交事务命令之前，发送提交事务命令之后）故障，导致资源阻塞。
T：try，指的是预留，即资源的预留和锁定，注意是预留
C：confirm，指的是确认操作，这一步其实就是真正的执行了
C：cancel，指的是撤销操作，可以理解为把预留阶段的动作撤销了
从思想上看和 2PC 差不多，都是先试探性的执行，如果都可以那就真正的执行，如果不行就回滚。
适用于对实时性要求没那么高的业务场景，如：短信通知
