https://blog.cndenis.com/tags/OTP.htmlRecent content in OTP on cnDenis的笔记Hugo -- gohugo.iozh-cnThu, 05 Jun 2014 00:00:00 +0000https://blog.cndenis.com/Erlang/2014/06/note_of_otp_supervior_tree.htmlThu, 05 Jun 2014 00:00:00 +0000https://blog.cndenis.com/Erlang/2014/06/note_of_otp_supervior_tree.html<p>这是Learn You Some Erlang中的<a class="link" href="http://learnyousomeerlang.com/building-applications-with-otp" target="_blank" rel="noopener" >Building an Applications with Otp</a>的笔记.</p> <p>在文中, OTP被戏称为Onion Theory Platform, 监控树像洋葱一样, 一层又一层.</p> <p>OTP的哲学是工人-监工, 工作进程做错事就让它死掉, 监督进程再开启新的工作进程来干活. 这样做有个让人觉得很麻烦的问题: 工作进程死掉了, 它的状态怎么办? 文中进行了讨论. 状态可以分成三类:</p> <ul> <li> <p>静态的状态. 这从配置文件读回来就可以, 没什么问题.</p> </li> <li> <p>动态但可重新获取的状态. 就是那些可以利用初始状态计算而来的东西, 重新算就行了.</p> </li> <li> <p>动态且不可重新获取的状态. 比如说用户的输入, 外部事件等等.</p> </li> </ul> <p>如果工作进程只有前两类状态, 用监工的方法很容易的处理, 死了重启, 恢复状态就可以了.</p> <p>第三类的状态需要放到不允许出错的地方(error kernel), 其实就是用try&hellip;catch包起来.</p> <p>作者示范了一个进程池的设计.</p> <p>所谓进程池, 就是可以容纳一定数量的进程同时运行, 当同时运行的进程数达到限制时, 把工作放入队列进行排队, 等待有空位时再开始新的任务.</p> <p>做这么一个进程池, 需要有一个服务进程来计数同时运行的工作进程数, 以及保存准备等待运行的队列.</p> <p>那用这个服务进程来监控工作进程好不好呢? 可以, 但缺点是服务进程任务太重, 而且和现有的监督者进程功能重复.</p> <p>一个比较好的方案是, 用一个监督进程<code>worker_sup</code>监视所有工作进程, 这个监督进程和进程池服务进程一起放到上一层的监督进程<code>ppool_sup</code>下, 如图:</p> <img src=http://learnyousomeerlang.com/static/img/ppool_sup.png> <p>如果让所有进程池都放在同一个<code>ppool_sup</code>下, 当一个进程池频繁出错的话, 这个<code>ppool_sup</code>会被关掉, 所有进程池都会被关掉, 这是很不好的事情. 所以要为每个进程池单独开一个监控进程. 变成这样:</p> <img src=http://learnyousomeerlang.com/static/img/ppool_supersup.png> <p>底下的具体实现部分就不记了.</p> <p>实现这么看起来并不太复杂的功能, 从顶层到worker, 总共四层, 不愧是洋葱理论平台.</p>