@PP
非常赞同！

类似的内容非原创、未获取许可的搬运和聚合性质的仓库，并不能保证内容的准确性和持续更新。

Github 的公信力和项目质量 lower and lower ~

GPL 的问题由来已久，这里有一篇分析比较完善的文章。
《为什么 GPL 是更好的开源许可证?》
http://www.ruanyifeng.com/blog/2010/02/why_gpl_is_a_better_choice.html

XXL-SSO 自荐一下！

http://www.xuxueli.com/xxl-sso/

http://www.xuxueli.com/xxl-conf/

动态推送更新，实时生效

https://github.com/xuxueli/xxl-job/

数百家企业用户登记接入

@loveCoding 你好，这些项目主要要社区一期来迭代维护的，后面有机会会考虑在社区内分享讨论的。

@ppdudu @Variazioni 是的，一致性 HASH 策略可行的，应该可以满足你的需求。
也可以结合执行器来做，可以为这个任务单独配置一个执行器，执行器选择手动注册，指定希望运行任务机器地址即可。

@petelin 借助内部广播机制实现的。集群节点可以秒级同步。相较于借助第三方组件如 eureka、zk 更加轻量。

@rrfeng 你好，是社区开源项目。

XXL 社区成立于 2015 年，是专门为支持开源软件项目而创办的一个非盈利性组织，负责发行和维护 XXL 系列开源软件，崇尚开放、自由和分享。

目前社区成员约 6000 人，维护项目包括 xxl-job，xxl-mq，xxl-rpc，xxl-registry ……等数十个。欢迎体验。

@notreami
@mortonnex
是的。
springboot 涉猎范围广，但是具体到每个点都不是很精深。现在这么流行，感觉很大程度上就是太简单，方便入门，产品质量怎么样还是其次。

小企业小团队初期，非常适合。但是到后面肯定都会结合业务，走上自研的路。

各大厂基础组件就看得出来了，基本上是自研然后适配 sc 方便使用，真正全部用 sc 的很罕见。

@mortonnex 确实有点频繁了。主要是最近新接入一些企业用户，反馈比较多。后面尽量保持固定发版周期。

@flame90 多谢反馈！
这是一个系列，一方面改名牵扯到十几个项目，另一方面暂时还没想到理想的名字，所以搁置了。

@janxin 多谢支持！

@liuxey 多谢关注，思路很不错！

现在大厂开源确实越来越多了，不过他强由他强、他弱由他弱，和 XXL 社区关系不大。

我们只是踏踏实实做我们的开源，服务好社区用户，迭代好每个产品，维护好几十个用户交流群。

XXL 系列项目都是社区推进迭代的，每个产品都在解决一个痛点，比如：

- XXL-JOB： http://www.xuxueli.com/xxl-job
- XXL-SSO： http://www.xuxueli.com/xxl-sso
- XXL-RPC： http://www.xuxueli.com/xxl-rpc
- XXL-MQ： http://www.xuxueli.com/xxl-mq
……

更多可前往： http://www.xuxueli.com/page/projects.html

@notreami 可以考虑，不过技术栈非 go，换起来时间成本比较大啊。
@qping 是的

单机 TPS 过万的 MQ，底层使用 Netty + Hessian 通讯（ XXL-RPC ）异步通讯，远远没达到上限 ~

@HuHui XXL-RPC 注册中心单独立项了，之前内部原生的所以是 “ Native ” 前缀，现在使用 XXL-REGISTRY 所以是 XxlRegistry 前缀。是为了与其他内置注册中心客户端实现保持统一（除了 XxlRegistry*** ，还有 ZK ***、Local *** 等多个内置开箱即用的注册中心实现）。

@HidingKing
～～～
配置中心我写了两年了，你们说的这些都有了解，底层原理优劣相信更熟悉一些，你提到的 disconf 已经两年没迭代处理 issue 了，应该已经被放弃了。

XXL-CONF 迭代两年期间，积累下来的二十多项特性，和一批企业级用户，已经体现了 XXL-CONF 价值。

docker hub 上将近 2000 次多次 pull 记录，也证明了 XXL-CONF 的易用性。

两行命令即可搭建运行配置中心，将开箱即用做到极致。我们还有 19 个社区 qq 群，社区也很活跃～

@tao1991123 XXL-CONF 比 nacos 提早发布两年，相较于其他同类型产品，拥有多项实用特性：

1、轻量级：无论单机还是集群部署，相较于同类产品保持更轻；
2、数据安全：多级 （ DB + 磁盘 + 镜像文件）数据存储，配置保证数据安全。
3、多级容灾：无论 DB 宕机、配置中心集群全节点宕机，甚至 DB+配置中心全部宕机，接入方毫无影响，可正常发布部署，等待配置中心回复后刷新同步最新配置数据。
4、动态推送更新：比如 Spring Bean 其中一个属性使用 XXL-CONF 配置，该配置更新后将会动态刷新该 Bean 该属性值，自动进行。
5、Web 界面：提供完善的用户、权限、人员、项目、配置管理功能，均可在线操作。

……

多环境、多语言、多数据类型

……

更多特性，可以参考文档。

@hhhsuan xxl-mq 相较于其他 mq 还是有差异的啊，比如：

并行消息：适用于吞吐量较大的消息场景，如邮件发送、短信发送等业务逻辑
串行消息：FIFO 方式串行消费；适用于严格限制并发的消息场景，如秒杀、抢单等排队业务逻辑；
广播消息：适用于广播场景，如广播更新缓存等
延时消息: 适用于延时消费场景，如订单超时取消等;
事务性: 开启事务开关后,消息事务性保证只会成功执行一次;
消息可追踪: 支持追踪每一条消息的执行路径, 便于排查业务问题;
……

这些特性往往更贴合业务需求，方便故障排错。