随着上一篇介绍Chaos的文章推送，最近有好几家公司或者项目负责人联系我，准备在生产环境中使用Chaos，所以也会经常被问到一些问题。这里我总结了一下经常会被问到的几个问题，给大家做一个统一的回答吧！
-
怎么样搭建Chaos的集群环境？
这个问题分为2步：
- 首先是配置mid：chaos的配置文件中有一个配置项是mid，这个mid就是每台chaos服务器的唯一标识，目前支持配置值是0-9的数字。只要在一个集群中保证每台chaos的mid不一样即可。
- 在chaos的前端放一个ngx或者是HA这种的带有“负载均衡”功能的反向代理服务器，将各自单台的chaos组合起来即可，我们用的是ngx； -
chaos进程起来都是“回话模式”，退出term就没了，怎么设置“后台运行”，难道要自己加&？
chaos当然不会傻到让使用方自己加&来daemon化，chaos的配置文件中有一个配置项daemon，把这一项设置成true即可。 -
chaos起不来，出现libev.so can not found的错误，这是怎么回事？
这是因为你虽然安装了libev，但是有的系统（比如centos）不会自动去更新系统的so缓存，所以你需要更新一下系统的so缓存。
- 执行命令：echo “/usr/local/lib” >> /etc/ld.so.conf.d/x86_x64_linux_libev.conf ；
- ldconfig -v
搞定。 -
为什么chaos起来后本地可以访问，换台机器就不能访问了？
首先你要排除一下你的防火墙，iptables之类的配置是不是都已经开启chaos所使用的端口了。如果已经支持了，那么请看一下chaos配置文件中的配置项bind_ip这个项的值是多少，默认是127.0.0.1，请将这个配置项改成chaos服务器所在的外网可以访问的ip，重启chaos，你就可以在另外一台机器上获取id了。 -
chaos在集群的情况下（特别是不同机器之间）生成的id是保证单调自增的吗？
不是，chaos生成的id在集群的情况下不保证严格的单调递增，特别是1s内生成的id，但chaos肯定保证2s内生成的id具有严格单调递增性，也就是说后一秒生成的id值肯定大于前一秒生成的id值。造成这个原因主要是因为几点：
- 严格单调递增不是不能做到，而是消耗的资源太多了。现在chaos在集群情况下是没有主从之分的，也没有相互之间的任何通讯，从而保证了我们获取一个id的快速性，也保证了chaos整个的简单性；
- 获取id后，我们经常做的一个动作就是分库分表操作，所以id会被根据业务规则散落到各个“段表”中，在这过程中，时间应该会在ms或者是s级别，所以chaos严格递增性其实没有那么大的实际需求，我们就可以不优先实现这个功能；
- 系统的健壮性。平行的chaos功能设计有利于chaos的部署简单化和提高chaos的系统鲁棒性，不管chaos的机器发生什么问题，就算机器down掉或者直接换掉，chaos都可以快速的通过使用新机器、新节点来提供新的功能，不需要恢复数据、操作日志（因为根本就没有，每次的id都是纯计算生成的）等等；
PS：我们有支持严格单调递增的id生成器，是另外一个系统：lax605。lax605在我们的系统中更多的被用来作为分布式协调器的角色使用，类似于zookeeper。 -
chaos生成的id是否存在浪费？怎么处理？
有浪费现象，比如现在每台机器每秒都可以支持最大2560000个id的生成，但是因为99.9999%的时候你根本就用不到那么多的id，真实的业务量大概每秒也就几百或者几千的id生成，从而因为id中存在序列号，所以没有被轮询到的id就直接被扔掉了，这确实有浪费现象。怎么处理？chaos就没有去处理，因为我们觉得这个没啥必要，反正每秒id那么多，而且对于业务来说如果分库分表规则是按照时间等作为路由是要严格保证时间上的正确性的，综上我们就不去过多的去做额外的处理了。但如果有业务方确实觉得id是一个虚缺资源，需要每一个都不放过，那么可以通过中继器来过渡一下，自己做一个每个id的存储和分发。但是在这么做之前，我觉得要冷静下来思考一个问题：这种做法真的有必要吗？ -
chaos生成的id最大值是多少？多长？长度固定吗？
chaos生成的是一个uint64的数，最大的长度是64位，一共最长是18个数字的长度。但是因为id和时间相关，所以开始的时候id的个数长度会比较短，大概在15位左右。所以id的长度是不固定的。 -
chaos的客户端有没有java的？
首先，chaos目前支持两种方式访问：tcp和http。java的客户端也确实有，并且也有开源（在albianj项目中），java的客户端就是通过tcp方式访问的。但就我们自己使用的实际情况和实际效果来看，我们不推荐使用java客户端的tcp方式，我们推荐大家更多的使用http来访问chaos，主要有几点：
- http相比tcp更容易调试，curl或者是浏览器就可以直接调试；
- http相比tcp，http没有语言的相关性需求，当一个公司或者项目大了以后不保证所有的功能都是java来实现的，所以客户端模式会很蛋疼的需要很多的客户端；
- 对于tcp的通讯相比http性能高的问题，chaos这种访问都是在内网，用http和tcp能差多少？ -
id生成器目前在公司内部使用的怎么样？
目前公司内部的内容中心、起点改造等站点正在使用id生成器，每天的请求量总体加起来过亿，一共花费了4台普通的pc服务器。id生成器从上线的那天开始一直到今天有2年多了，中间除了因为功能增加以外从来没有down机，也没有重启记录。稳定性达到惊人的100%。可以算是公司内最稳定的线上运行项目，没有之一。 -
目前有几家公司正在使用？
到今天为止，一共有10+家公司已经在线上使用id生成器，目前来咨询有使用意向的也有7-8家。我们是最大的一家：阅文集团，该集团是腾讯文学、盛大文学合并而成的。请求量和数据量在网络文学届也是数一数二的。 -
评价一下别的id生成器，和chaos有什么差别？
这nm怎么评价，谁都是看自己家的孩子更好看，更可爱啊！不要搞事啊！我严重怀疑问我这个问题的人的居心，但一看问这个问题的还挺多。nm，果然都是来搞事的。不过话说回来，虽然我确实看了很多友商的id生成器设计或者是成品，各有千秋，各有优势吧！我觉得我们的chaos主要有几个优势：
- 在架构上更加的简单，平行化的设计，没有单点或者主从的问题，也没有机器的浪费问题，都是主；
- 依赖少，除了依赖网络库libev，没有什么mysql数据库或者redis这种依赖（PS：其实我也觉得很奇怪，为嘛一个id生成器需要依赖数据库或者是redis这种玩意，这种东西到底在id生成器中有啥用？除了复杂化设计外，没看到什么必要）；
- 性能上更牛X一些吧，c语言，事件机制，相比java之类的，那是相当妥妥的；
- 可读性上更人性化一些，十进制的数字，基本上都能看的懂；
- 协议更简单一些，支持http，无语言相关性；
- 更适合作为数据库的主键来使用，特别是需要做分布式数据库的情况，有分库分表等等数据路由的情况特别适合；