程序员修神之路分布式高并发
程序员修神之路--分布式高并发下Actor模型如此优秀
一般来说有两种策略用来在并发线程中进行通信：共享数据和消息传递。使用共享数据方式的并发编程面临的最大的一个问题就是数据条件竞争。处理各种锁的问题是让人十分头痛的一件事。
传统多数流行的语言并发是基于多线程之间的共享内存，使用同步方法防止写争夺，Actors使用消息模型，每个Actor在同一时间处理最多一个消息，可以发送消息给其他Actor，保证了单独写原则。从而巧妙避免了多线程写争夺。和共享数据方式相比，消息传递机制最大的优点就是不会产生数据竞争状态。实现消息传递有两种常见的类型：基于channel（golang为典型代表）的消息传递和基于Actor（erlang为代表）的消息传递。
Actor简介Actor模型(Actor model)首先是由Carl Hewitt在1973定义， 由Erlang OTP 推广，其 消息传递更加符合面向对象的原始意图。Actor属于并发组件模型，通过组件方式定义并发编程范式的高级阶段，避免使用者直接接触多线程并发或线程池等基础概念。
Actor模型=数据+行为+消息。
Actor模型是一个通用的并发编程模型，而非某个语言或框架所有，几乎可以用在任何一门编程语言中，其中最典型的是erlang，在语言层面就提供了Actor模型的支持，杀手锏应用RabbitMQ 就是基于erlang开发的
更加面向对象Actor类似面向对象编程（OO）中的对象，每个Actor实例封装了自己相关的状态，并且和其他Actor处于物理隔离状态。举个游戏玩家的例子，每个玩家在Actor系统中是Player 这个Actor的一个实例，每个player都有自己的属性，比如Id，昵称，攻击力等，体现到代码级别其实和我们OO的代码并无多大区别，在系统内存级别也是出现了多个OO的实例
class PlayerActor
{
public int Id { get; set; }
public string Name { get; set; }
}在使用Java/C# 等语言进行并发编程时需要特别的关注锁和内存原子性等一系列线程问题，而Actor模型内部的状态由它自己维护即它内部数据只能由它自己修改(通过消息传递来进行状态修改)，所以使用Actors模型进行并发编程可以很好地避免这些问题。Actor内部是以单线程的模式来执行的，类似于redis，所以Actor完全可以实现分布式锁类似的应用。
异步每个Actor都有一个专用的MailBox来接收消息，这也是Actor实现异步的基础。当一个Actor实例向另外一个Actor发消息的时候，并非直接调用Actor的方法，而是把消息传递到对应的MailBox里，就好像邮递员，并不是把邮件直接送到收信人手里，而是放进每家的邮箱，这样邮递员就可以快速的进行下一项工作。所以在Actor系统里，Actor发送一条消息是非常快的。
这样的设计主要优势就是解耦了Actor，数万个Actor并发的运行，每个actor都以自己的步调运行，且发送消息，接收消息都不会被阻塞。
每个Actor的实例都维护这自己的状态，与其他Actor实例处于物理隔离状态，并非像 多线程+锁 模式那样基于共享数据。Actor通过消息的模式与其他Actor进行通信，与OO式的消息传递方式不同，Actor之间消息的传递是真正物理上的消息传递。
天生分布式每个Actor实例的位置透明，无论Actor地址是在本地还是在远程机器上对于代码来说都是一样的。每个Actor的实例非常小，最多几百字节，所以单机几十万的Actor的实例很轻松。如果你写过golang代码，就会发现其实Actor在重量级上很像Goroutine。由于位置透明性，所以Actor系统可以随意的横向扩展来应对并发，对于调用者来说，调用的Actor的位置就在本地，当然这也得益于Actor系统强大的路由系统。
生命周期
每个Actor实例都有自己的生命周期，就像C# java 中的GC机制一样，对于需要淘汰的Actor，系统会销毁然后释放内存等资源来保证系统的持续性。其实在Actor系统中，Actor的销毁完全可以手动干预，或者做到系统自动化销毁。
容错说到Actor的容错，不得不说还是挺令人意外的。传统的编程方式都是在将来可能出现异常的地方去捕获异常来保证系统的稳定性，这就是所谓的防御式编程。但是防御式编程也有自己的缺点，类似于现实，防御的一方永远不能100%的防御住所有将来可能出现代码缺陷的地方。比如在java代码中很多地方充斥着判断变量是否为nil，这些就属于防御式编码最典型的案例。但是Actor模型的程序并不进行防御式编程，而是遵循“任其崩溃”的哲学，让Actor的管理者们来处理这些崩溃问题。比如一个Actor崩溃之后，管理者可以选择创建新的实例或者记录日志。每个Actor的崩溃或者异常信息都可以反馈到管理者那里，这就保证了Actor系统在管理每个Actor实例的灵活性。
劣势天下无完美的语言，框架/模型亦是如此。Actor作为分布式下并发模型的一种，也有其劣势。
01由于同一类型的Actor对象是分散在多个宿主之中，所以取多个Actor的集合是个软肋。比如在电商系统中，商品作为一类Actor，查询一个商品的列表在多数情况下经过以下过程：首先根据查询条件筛选出一系列商品id，根据商品id分别取商品Actor列表（很可能会产生一个商品搜索的服务，无论是用es或者其他搜索引擎）。如果量非常大的话，有产生网络风暴的危险（虽然几率非常小）。在实时性要求不是太高的情况下，其实也可以独立出来商品Actor的列表，利用MQ接收商品信息修改的信号来处理数据一致性的问题。02在很多情况下基于Actor模型的分布式系统，缓存很有可能是进程内缓存，也就是说每个Actor其实都在进程内保存了自己的状态信息，业内通常把这种服务成为有状态服务。但是每个Actor又有自己的生命周期，会产生问题吗？呵呵，也许吧。想想一下，还是拿商品作为例子， 如果环境是非Actor并发模型，商品的缓存可以利用LRU策略来淘汰非活跃的商品缓存，来保证内存不会使用过量，如果是基于Actor模型的进程内缓存呢，每个actor其实就是缓存本身，就不那么容易利用LRU策略来保证内存使用量了，因为Actor的活跃状态对于你来说是未知的。
03分布式事物问题，其实这是所有分布式模型都面临的问题，非由于Actor而存在。还是以商品Actor为例，添加一个商品的时候，商品Actor和统计商品的Actor（很多情况下确实被设计为两类Actor服务）需要保证事物的完整性，数据的一致性。在很多的情况下可以牺牲实时一致性用最终一致性来保证。
04每个Actor的mailBox有可能会出现堆积或者满的情况，当这种情况发生，新消息的处理方式是被抛弃还是等待呢，所以当设计一个Actor系统的时候mailBox的设计需要注意。
写在最后 升华一下1
通过以上介绍，既然Actor对于位置是透明的，任何Actor对于其他Actor就好像在本地一样。基于这个特性我们可以做很多事情了，以前传统的分布式系统，A服务器如果想和B服务器通信，要么RPC的调用（http调用不太常用），要么通过MQ系统。但是在Actor系统中，服务器之间的通信都变的很优雅了，虽然本质上也属于RPC调用，但是对于编码者来说就好像在调用本地函数一样。其实现在比较时兴的是Streaming方式。
2由于Actor系统的执行模型是单线程，并且异步，所以凡是有资源竞争的类似功能都非常适合Actor模型，比如秒杀活动。3基于以上的介绍，Actor模型在设计层面天生就支持了负载均衡，而且对于水平扩容支持的非常好。当然Actor的分布式系统也是需要服务注册中心的。
4虽然Actor是单线程执行模型，并不意味着每个Actor都需要占用一个线程，其实Actor上执行的任务就像Golang的goroutine一样，完全可以是一个轻量级的东西，而且一个宿主上所有的Actor可以共享一个线程池，这就保证了在使用最少线程资源的情况下，最大量化业务代码。
程序员修神之路--高并发下为什么更喜欢进程内缓存
进程内缓存是指缓存和应用程序在相同地址空间。即同一个进程内。分布式缓存是指缓存和应用程序位于不同进程的缓存，通常部署在不同服务器上。
从前有个机构，机构的主人叫做 CPU，这个机构专门派仆人取一些东西然后做相应的处理。下面是这个机构日常的场景。
cpu
赶紧去我的仓库L1缓存取点东西
--主人你要的东西，那里离我们最近，所以很快，但是空间比较小。
cpu
你丫还挺快，只用了大约一秒
赶紧去仓库 L2缓存取点东西
--主人你要的东西，那里离我们也很近，比L1缓存远一点，但是也很快，空间比较小，但是比L1缓存的空间大。
cpu
速度还可以，大约20秒就回来了
街上有一个地方叫内存，赶紧去取点东西
--主人你要的东西，内存这个地方空间很大呀，就是稍微远了点
cpu
居然用了5分钟，等你这段时间我都刷了好几个段子了
有一个叫做磁盘的小镇，赶紧去取点东西
--主人你要的东西，磁盘这个地方空间太大呀，取点东西很慢呀
cpu
居然用了5天，等你这段时间我都能抱团来一个周边游了
有一个叫做互联网的国度，赶紧去取点东西
--主人你要的东西，互联网太远了，取点东西太费劲了
cpu
居然用了15天，等你去互联网取东西，简直就是在浪费我的生命
当我做完一个委托人的任务，切换到另外一个委托人的任务时候，我需要把上一个委托人的一些信息先记录下来，然后还需要把新委托人的信息读取一遍，这个过程我是很耗时的，大约需要一个小时呢
以上故事纯属预估数据，真实数据会根据不同的硬件配置和网络环境有误差。
通过以上不正经的小故事，我们可以了解到cpu取各个设备数据的大体差距。至于YY妹子的问题，大家也应该了解了。
1. 首先把数据从磁盘加载到内存做缓存，这个是对的。毕竟磁盘的IO速度比内存要慢的多。就拿我们现在使用的大多数PC机以及服务器来说，磁盘往往是性能的瓶颈。
2. 如果有条件或者框架支持可以实现进程内缓存，我还是推荐使用进程内缓存，毕竟类似Redis这样的kv存储和应用程序多数情况不在一台服务器上，虽然局域网的速度肉眼看起来非常快，但是对于cpu来讲，还是让cpu休了一个大假。
至于什么情况下适合应用进程内缓存，我觉得有几点需要注意：
1. 相同的请求或者设置的相同缓存key的请求每次都是同一个服务器上的同一个程序去处理，这样这个请求的缓存正常情况下只会产生一份。 如果每次请求都会路由到不同的服务器，便会产生多个缓存的副本，维护这些缓存数据的一致性是需要代价的。
2. 当有新的服务器节点加入或者服务器节点退出的时候，不能发生雪崩现象，所有缓存请求都穿透到达数据库，那是比较要命的。比如可以看一下菜菜以前的文章：分布式缓存的一条明路（附代码）
3. 如果缓存的处理服务器发生变化，比如：由于某种原因，开始请求是由服务器A来处理，后来A服务器down了，现在由服务器B来处理，在缓存转移的过程中，必须能保证数据的正确性和一致性。
4. 程序的进程内缓存必须有过期策略，在有限内存大小的情况下，合理的使用。推荐使用LRU淘汰算法来保证内存不会撑爆。
5. 系统的并发量及其大，对性能的要求及其高，可以考虑使用进程内缓存。
6. 如果是小部分只读数据，并且访问量比较大，例如经常使用的字典数据等，可以考虑使用进程内缓存。
相对于分布式缓存，比如Redis，进程内缓存有哪些优势呢？
1. 进程内缓存性能比较高，延迟会更小，更节省带宽，毕竟分布式缓存网络调用的性能和本地调用比起来慢太多，
2. 由于和应用程序位于同一进程，共享相同的虚拟内存，所以在状态维护上更容易一些，
3. 其次进程内的缓存不设计到网络传输，所以没有序列化的过程，在性能上更胜一筹。
4. 进程内缓存的数据类型几乎可以是语言级别支持的任意类型，数据类型设计上比大多数分布式缓存设备支持要灵活许多。
在应对高并发的情况下，如果有适当的环境菜菜还是觉得进程内缓存为首选，另外一点程序要尽量避免线程切换，尽量异步化。如果可以最好能预估出缓存数据的大小，避免内存泄漏等现象发生。
当然分布式缓存有自己的优势，在监控，容灾，扩展性，易用性等方面更胜一筹。至于用进程内还是分布式缓存，没有定论，能解决业务痛点就是最好的结果
写在最后
程序如果要想最大程度的提升并发量，缩短响应时间， 就把用户需要的数据放在离用户最近的地方
程序员修神之路--高并发优雅的做限流（有福利）
如果你比较关注现在的技术形式，就会知道微服务现在火的一塌糊涂，当然，事物都有两面性，微服务也不是解决技术，架构等问题的万能钥匙。如果服务化带来的利大于弊，菜菜还是推荐将系统服务化。随着服务化的进程的不断演化，各种概念以及技术随之而来。任何一种方案都是为了解决问题而存在。比如：熔断设计，接口幂等性设计，重试机制设计，还有今天菜菜要说的限流设计，等等这些技术几乎都充斥在每个系统中。
就今天来说的限流，书面意思和作用一致，就是为了限制，通过对并发访问或者请求进行限速或者一个时间窗口内的请求进行限速来保护系统。一旦达到了限制的临界点，可以用拒绝服务、排队、或者等待的方式来保护现有系统，不至于发生雪崩现象。
限流就像做帝都的地铁一般，如果你住在西二旗或者天通苑也许会体会的更深刻一些。我更习惯在技术角度用消费者的角度来阐述，需要限流的一般原因是消费者能力有限，目的为了避免超过消费者能力而出现系统故障。当然也有其他类似的情况也可以用限流来解决。
限流的表现形式上大部分可以分为两大类：
1. 限制消费者数量。也可以说消费的最大能力值。比如：数据库的连接池是侧重的是总的连接数。还有菜菜以前写的线程池，本质上也是限制了消费者的最大消费能力。
2. 可以被消费的请求数量。这里的数量可以是瞬时并发数，也可以是一段时间内的总并发数。菜菜今天要帮YY妹子做的也是这个。
除此之外，限流还有别的表现形式，例如按照网络流量来限流，按照cpu使用率来限流等。按照限流的范围又可以分为分布式限流，应用限流，接口限流等。无论怎么变化，限流都可以用以下图来表示：
◆◆常用技术实现◆◆
令牌桶算法
令牌桶是一个存放固定容量令牌的桶，按照固定速率往桶里添加令牌，填满了就丢弃令牌，请求是否被处理要看桶中令牌是否足够，当令牌数减为零时则拒绝新的请求。令牌桶允许一定程度突发流量，只要有令牌就可以处理，支持一次拿多个令牌。令牌桶中装的是令牌。
漏桶算法
漏桶一个固定容量的漏桶，按照固定常量速率流出请求，流入请求速率任意，当流入的请求数累积到漏桶容量时，则新流入的请求被拒绝。漏桶可以看做是一个具有固定容量、固定流出速率的队列，漏桶限制的是请求的流出速率。漏桶中装的是请求。
计数器
有时我们还会使用计数器来进行限流，主要用来限制一定时间内的总并发数，比如数据库连接池、线程池、秒杀的并发数；计数器限流只要一定时间内的总请求数超过设定的阀值则进行限流，是一种简单粗暴的总数量限流，而不是平均速率限流。
除此之外，其实根据不同的业务场景，还可以出现很多不同的限流算法，但是总的规则只有一条：只要符合当前业务场景的限流策略就是最好的
限流的其他基础知识请百度！！
◆◆优雅解决妹子问题◆◆回归问题，YY妹子的问题，菜菜不准备用以上所说的几种算法来帮助她。菜菜准备用一个按照时间段限制请求总数的方式来限流。 总体思路是这样：
1. 用一个环形来代表通过的请求容器。
2. 用一个指针指向当前请求所到的位置索引，来判断当前请求时间和当前位置上次请求的时间差，依此来判断是否被限制。
3. 如果请求通过，则当前指针向前移动一个位置，不通过则不移动位置
4. 重复以上步骤 直到永远.......
◆◆用代码说话才是王道◆◆
以下代码不改或者稍微修改可用于生产环境
以下代码的核心思路是这样的：指针当前位置的时间元素和当前时间的差来决定是否允许此次请求，这样通过的请求在时间上表现的比较平滑。
思路远比语言重要，任何语言也可为之，请phper，golanger，javaer 自行实现一遍即可
//限流组件,采用数组做为一个环
class LimitService
{
//当前指针的位置
int currentIndex = 0;
//限制的时间的秒数，即：x秒允许多少请求
int limitTimeSencond = 1;
//请求环的容器数组
DateTime?[] requestRing = null;
//容器改变或者移动指针时候的锁
object objLock = new object();
public LimitService(int countPerSecond,int _limitTimeSencond)
{
requestRing = new DateTime?[countPerSecond];
limitTimeSencond= _limitTimeSencond;
}
//程序是否可以继续
public bool IsContinue()
{
lock (objLock)
{
var currentNode = requestRing[currentIndex];
//如果当前节点的值加上设置的秒 超过当前时间，说明超过限制
if (currentNode != null&& currentNode.Value.AddSeconds(limitTimeSencond) >DateTime.Now)
{
return false;
}
//当前节点设置为当前时间
requestRing[currentIndex] = DateTime.Now;
//指针移动一个位置
MoveNextIndex(ref currentIndex);
}
return true;
}
//改变每秒可以通过的请求数
public bool ChangeCountPerSecond(int countPerSecond)
{
lock (objLock)
{
requestRing = new DateTime?[countPerSecond];
currentIndex = 0;
}
return true;
}
//指针往前移动一个位置
private void MoveNextIndex(ref int currentIndex)
{
if (currentIndex != requestRing.Length - 1)
{
currentIndex = currentIndex + 1;
}
else
{
currentIndex = 0;
}
}
}测试程序如下：
static LimitService l = new LimitService(1000, 1);
static void Main(string[] args)
{
int threadCount = 50;
while (threadCount >= 0)
{
Thread t = new Thread(s =>
{
Limit();
});
t.Start();
threadCount--;
}
Console.Read();
}
static void Limit()
{
int i = 0;
int okCount = 0;
int noCount = 0;
Stopwatch w = new Stopwatch();
w.Start();
while (i < 1000000)
{
var ret = l.IsContinue();
if (ret)
{
okCount++;
}
else
{
noCount++;
}
i++;
}
w.Stop();
Console.WriteLine($"共用{w.ElapsedMilliseconds},允许：{okCount}, 拦截：{noCount}");
}测试结果如下：
最大用时15秒,共处理请求1000000*50=50000000 次
并未发生GC操作，内存使用率非常低，每秒处理 300万次+请求 。以上程序修改为10个线程，大约用时4秒之内
如果是强劲的服务器或者线程数较少情况下处理速度将会更快
写在最后以上代码虽然简单，但是却为限流的核心代码（其实还有优化余地），经过其他封装可以适用于Webapi的filter或其他场景。
浙公网安备 33010602011771号