TaskDispatcher

[fan2008shuai]

• 为什么使用“任务分发模型”？虽然它实现了流量塑形、任务过期、任务去重等功能，但Eureka的这种“生产者消费者模型”感觉实现有些复杂。用简单的生产者消费者模型好像也能实现这种功能。为什么要使用三个队列：acceptorQueue/reprocessQueue, pendingTasks, itemWorkQueue？真的有必要吗？
• client在发现session server的时候需要先传一个session server的hostPort？需要物理机部署多个session server（如果是一个session server的话，有单点的风险）？现在在进行docker化，蚂蚁怎么部署的？如果是用物理机的话，一个session server物理机硬件宕机，还需要新启动的服务使用刚宕机的IP或者记得修改DNS？难道LVS或HaProxy？ 辛苦解惑一下。谢谢！

[sofastack-bot[bot]]

Hi @fan2008shuai, we detect non-English characters in the issue. This comment is an auto translation by @sofastack-robot to help other users to understand this issue.

We encourage you to describe your issue in English which is more friendly to other users.

• Why use the "Task Distribution Model"? Although it implements functions such as traffic shaping, task expiration, and task deduplication, Eureka's "producer consumer model" feels somewhat complicated to implement. It seems that this function can also be achieved with a simple producer consumer model. Why use three queues: acceptorQueue/reprocessQueue, pendingTasks, itemWorkQueue? Is it really necessary? - When the client discovers the session server, it needs to pass a session server's hostPort first? Need a physical machine to deploy multiple session servers (if it is a session server, there is a single point of risk)? Now in the dockerization, how is the ant deployed? If the physical machine is used, a session server physical machine hardware is down, do you need a newly started service to use the IP of the machine or remember to modify the DNS? Is it LVS or HaProxy? Work hard to understand. Thank you!

[Synex-wh]

不好意思，回复的晚了 1、对于使用task模型我们当时考虑到在session一侧是所有地址变更的推送主体，这些推送和一些过程执行需要异步化和统一的重试机制，所以考虑大任务模型，我们目前任务模型确实模仿了Eureka的实现，只是增加了重试和一些任务过期判断。统一使用这个模型的好处是可以确定固定活跃线程数量进行某一类任务处理，可以统一进行任务队列执行情况监控，当时还考虑到我们可能存在批量任务执行的可能这个模型是支持批次执行固定数量任务（目前没有用到），同时统一的任务模型对外是一致编程方式比较好扩展和添加新的任务类型。至于你说的生产消费模式当然就是这套任务模型的基本原理，当然直接使用线程池来处理也是可以的 2、client发现session的方式是通过固定的9603端口随便访问一台session机器就可以，我们内部这个随便一台session机器是采用域名映射一台的，具体目前配置的dns服务，在通过这个9603提供的http接口返回真实集群的session列表进行长连接后交互数据的

[fan2008shuai]

没关系，你们也很忙，理解

• 嗯，这种任务模型实现了重试、过期、去重、塑形、队列监控等功能，而且扩展性强。也许使用线程池实现一套出来，经过优化、重构代码之后，可能会演进成这种样子。
• DNS服务的域名指向session集群的一台具体的物理机IP？在注册中心初始化的过程中，这个物理机承担的所有client的流量？如果这个物理机挂了怎么办？新的client启动的时候无法获取到session列表，单纯依靠client的重试机制，等待DNS域名指向其他的session物理机IP？内部DNS域名指向会自动检测所指向的IP机器是否存活，然后切换到备用IP机器，而不是手动？session服务是纯物理机部署吗？还是IP固定的类似于docker的虚拟化产品？

[fan2008shuai]

• 还有一个问题。注册中心在公司内部是同一套集群吗？比如除了sofa-rpc需要注册之外，其他业务也有注册发现的需求，那么这个业务的注册中心会跟sofa-rpc共用一套注册中心吗？

[Synex-wh]

1、DNS服务的域名是指session所有容器也好虚机也好，前面有一个dns服务器映射这些ip对应的域名，比如“xxx.alipay.registry.net”这样，客户端首次链接通过”http://xxx.alipay.registry.net:9603“ 访问，随机获取到一个session，session上的集群内其他session地址是通过meta定期获取并推送到session上的，这样地址列表是准确并且最新的。session不一定是物理机，我们云上都部署的是docker容器ip确实是浮动的，但是只要启动就会去meta注册具体ip，并且分发给每个session

2、注册中心目前我们不只一套集群，按照不同域有所划分，不过都主要是提供rpc服务注册发现的，你说的其他注册发现需求不知道是指啥，如果是配置相关不在注册中心是在配置中心

[fan2008shuai]

• 如果session部署在docker容器（IP浮动），session上下线之后，上线之后的IP列表与上线前的IP列表不一样了，还要更新DNS（手动或自动）以保证域名指向是对的？
• 比如手机端push这种与服务器直连的场景，手机端通过API层动态感知服务器列表，这种非RPC提供的一些服务，也需要注册发现的机制。