Scher与Jinwei是我们任务调度的两个不同类型的区分。他们分别完成定时和实时任务的调度。

    它们基于Albianj实现，有着相同的物理与逻辑架构，并且有着90%重叠的功能，但是我们却在设计、开发与部署的时候进行了强制性的隔离，这里的原因痛苦而无奈，想知道为什么吗？来，我告诉你。

    ▍ 2. 高性能开发为主的中间件设计与实现。这部分主要由linux下的C开发为主，主要讲述我们自我实现的分布式id生成器Chaos，分布式文件系统DFS、分布式缓存系统lest与分布式协调器lax，通讯协议hms与使用JNI实现的http服务Aru。分布式id生成器Chaos主要为我们的业务生成全站的、可视化、区间内单调递增的id，用于取代老旧的MySQL自增id或者是uuid作为主键的方案。

    Chaos生成的id和albianj的数据路由进行紧密的配合，可以使开发者在无感知、无侵入的情况下快速而有效的开发出可以抵挡亿级PV的分布式业务系统。DFS就不用多说了，这是一个互联网公司走向中间件自主的必经之路，也是标志之一。因为我们业务的特殊性，要求对于DFS存储的内容可进行频繁的更改，所以市面上其实并无相应的成熟DFS可用，故我们别无选择。我们在DFS上花了很大的时间进行设计和优化，使其满足我们每天亿级新增/更改的需求。有了DFS的内容存储，我们又对其增加了一个出口：这就是我们的Arch系统。说起Arch系统，这仅仅是出于我们自己的看不惯和“2”的精神。因为觉得netty太过复杂，所以就动了自己写一个精简NIO的恻隐之心，所以就在“好玩”的驱使下，我们使用JNI自己封装了一个C版本的NIO，然后因为想试试它的完备性、健壮性和性能，思来想去http简单，那就搞一个小心的http服务器吧。所以arch由此诞生。目前arch运行在我们的图片、音频等项目中，为漫画、精排、封面提供每天亿级访问的服务。对于图片、音频等当然是主要输出就可以了。但是对于内容就没有那么简单了，所以我们在DFS上又增加了一套基于大数据和AI的关键字鉴别与分析系统，这样将DFS完整的平台化。分布式缓存系统lest和分布式协调器lax则不同，他们的出现来自于我们对于缓存管理的无奈和懊恼，还有对于zookeeper的失望。以前我们的缓存使用了26台的redis来进行管理，机器数量增加的同时也增加了成本，并且redis客户端的分布式模式时间长了真的很难管理。所以我们开发了lest，一个不需要大内存而基于ssd的缓存系统。为了给lest增加严格的版本控制，实验了zookeeper，不管是部署还是性能，都不满足我们的需求和胃口，再者zk的功能太多了，我们又及其讨厌开源软件的“复杂税”，所以在迫于无奈的情况下，我们只能自己开发了分布式协调器lax。从而将lest和lax组合成一个完整的系统。