linxin

> In JDK1.7 there is a better way to generate random numbers under multithreading.I think we can use ThreadLocalRandom instead normal Random,also we should think over lower version JDK.May I...

当前都是基于TCP协议的版本，没有验证过UDP。 建议对照Netty的UDP使用来尝试是否可以拓展，如果有没法拓展的接口请联系我。欢迎提PR来共建！

Very good suggestion, you are welcome to submit a PR to simplify the dependence on Netty.

这是一个不好的实现，没有管理好内部的eventExecutor，应该让它跟着RpcClient一起被回收掉。 我后面的版本会修复这个问题。

> 最早是V5的时候，有watcher、publisher和subscriber等概念，作为几种不同类型的客户端，存储在不同的“Store”里面，这么设计也是最初V5使用了多个线程池，通过task对象进行解耦，所以，将元信息封装在“model”对象中。 > > 而V6我们改版时候，经过压测等手段，发现异步解耦有如下问题： > > 1. 实战下来，过度地一步解耦导致对象之间的关系不明确，很容易混淆，加之没有单测，很容易出现问题 > 2. 性能大坑，无法很好处理IO类任务和计算类任务，以及优先级问题 > > 后来，针对异步队列进行了解耦，但是留下了原有的对象，存储。 > > 再后来，对象本身好像被加了一些定义，这个 @bjxiaojian 比较清楚 1. 如果缺少单测应该补充单测，我觉得这个不是问题 2. 不知道这一点的性能的坑具体只什么，是对象转换带来的申请内存的开销吗？

> * Subscriber作为一个对象，我理解是可以有包含对象自身特性的一些方法的，比如截图中的Subscriber对象是否被推送过，我理解这个不属于具体的业务逻辑； 如果这个对象是common.model.store下的，我建议是不要带有”业务逻辑“。 结合一下DataStore#add方法，Publisher、UnPublisher、Subscriber、Watcher都是能被add到DataStore里面的，以及他们实现了Serializable接口，所以他们应该是数据模型。就像你要像DB插入一行数据，你插入的肯定是数据，而不是数据结构。

> > > 最早是V5的时候，有watcher、publisher和subscriber等概念，作为几种不同类型的客户端，存储在不同的“Store”里面，这么设计也是最初V5使用了多个线程池，通过task对象进行解耦，所以，将元信息封装在“model”对象中。 > > > 而V6我们改版时候，经过压测等手段，发现异步解耦有如下问题： > > > > > > 1. 实战下来，过度地一步解耦导致对象之间的关系不明确，很容易混淆，加之没有单测，很容易出现问题 > > > 2. 性能大坑，无法很好处理IO类任务和计算类任务，以及优先级问题 > > > > > > 后来，针对异步队列进行了解耦，但是留下了原有的对象，存储。 > >...

Publisher、UnPublisher、Subscriber、Watcher，其中UnPublisher甚至不是一个名词

感觉好像没理解我表达的意思。 1. 如果这四个类代表的是一类数据，比如代码中的StoreData（他们确实都实现了StoreData），那他们应该都是一类存储数据，存储数据上显然不应该有类似下面的代码：  2. Publisher\Subscriber\Watcher代表的都是什么，他们三个是三个名词，代表的是一个Pub动作或者Sub动作上来吗？UnPublisher不是一个名词