2019-10-30Actor 模型不适用于对消息处理顺序有严格要求的系统。因为在 Actor 模型中，消息均为异步消息，无法确定每个消息的执行顺序。虽然可以通过阻塞 Actor 去解决顺序问题，但显然，会严重影响 Actor 模型的任务处理效率。 6
2019-12-09阻塞则需要锁，actor本来的目的就是去锁化，与初衷背道而驰。
2019-11-16全程都是在通信呢，跟计算有啥关系？
为什么这个算是计算模式的内容，而不是通信技术
2019-11-14如果使用阻塞的形式，各个actor会发生雪崩的现象，导致整个系统不可用
2019-11-11为什么认为Actor模式是计算模式呢？感觉更属于通信模式啊
2019-11-10我觉得如果要保证消息处理顺序不一定要阻塞actor吧。每个actor都是单线程，只要每个actor都只有一个instance，那即便是异步处理也能保证消息处理顺序。这就像是消息队列，只要保证一个partition只有一个consumer在consume消息，这个partition的消息就可以保证顺序。
而且这个时候阻塞actor也没有用，因为下游的actor不会给一个response来确认消息已被成功处理。因为actor model里面本来大家都是异步的，是没有response机制的。- 2019-11-09参考zeromq，一样能够实现同步调用，虽然阻塞，但可以通过异步时间模型
2019-11-02我理解得是，Actor用mailbox（队列）就是方便存放暂时无法处理的消息；如果变成阻塞的这个mailbox元素个数就始终为1，那么这个mailbox还有存在的必要吗。
用JUC做类比，有ThreadPoolExecutor，用线程池加队列来高效处理任务；也有Exchanger这样一个线程生成一个消息，另一个才可以消费消息。
总之，利用合适的工具做合适的事，不能拿着锤子，看着什么都是钉子。展开
2019-10-31没接触过分布式的相关知识，看完有点不明觉厉 1
2019-10-30是不是如果采用阻塞方式的话，比如有一个Actor发生阻塞，那与之关联的其它Actor为了等待任务的完成也会发生阻塞。因为Actor组成的网络结构是动态的，并没有一个预定的结构，因此会导致两个结果：
1、为了完成任务，被动阻塞的Actor新建Actor导致网络野蛮生长。
2、或者Actor的阻塞发生链式反应，最终导致整个系统可用性大幅下降。
异步方式就是为了解耦各个Actor，如果采用阻塞的模型，就与这个初衷南辕北辙了吧。
另外，感觉Actor模型和高并发网络编程中的reactor模型很像，虽然reactor模型不是分布式的，但是思路很像。展开
2019-10-30简单思考了一下，Actor采用阻塞方式执行的话，很有可能出现多个Actor向一个Actor发消息，如果某个Actor发送的消息较大，或执行计算时被阻塞，后面的Actor再发送消息都会被阻塞，系统可用性就大大降低。
ps：跟着老师不仅能学分布式知识，还可以学到程序员必备技能—甩锅😂
2019-10-30有点抓不住问题的关键点，感觉问的很模糊。
阻塞执行没啥不可以吧，效率低点而已，比如每个actor多线程调用队列中的任务，然后阻塞等待其他的actor，(不知道有没有这种用法）跟普通的分布式没啥区别。
不过actor得目标就是快速分布式计算，如果阻塞导致整体任务卡死，那就不如不要用他了。展开