继续改进部分基于用户好友关系的分布式PubSub系统。

本来的想法是把LocalSubList放到远端，好处是High availability即某个节点死了不会造成大面积故障，由另外一个节点可迅速接管。但是如果放在远端, 那更新的开销会非常大, 1个改变需要修改n份远程数据，比如拿在线好友列表说事，一个用户改变状态，所有在线好友的列表需要同时update，在设计上人为制造了一个瓶颈。

因此今天把思路调整下，由发送方广播1个通知, 接收方各自维护更新自己的列表。那HA怎么办，每2个节点分成一组互相替对方存一份。反正发送方会广播通知的，即使增加一个专用的节点来做备份listener也不是什么大问题。在可靠性面前，硬件成本微不足道。

自己做一个网络模块的优点是风险可控，时间可控，但是原理通过之后就只剩下枯燥的开放了。按照don't re-invent the wheel的思想，或许将来更好的做法是底层(语言和框架)来做这些事情。比如网络间的通讯，节点迁移，HA, 数据共享等。

这个模块有点抽象，尽管我觉得不复杂，但跟别人口述的时候对方也是听得一头雾水，从软件项目管理的角度来说设计要尽量简单，至少要项目小组里面一半以上的人一看就明白，因此这个设计还有很大的简化空间。

做软件设计不能做得象编程之美的题目那样高深。对于一个网络服务端程序，我觉得
1. 性能优先
2. 简单优先