Apache Ignite 2.5: 千级节点伸缩性
Apache Ignite的用户通常知道的两个关键点是-扩展性和性能。在很多分布式系统的整个生命周期中，通常会不停地改进性能，而对扩展性相关的改进次数，会比较少。这不是不关注于扩展性，而是因为分布式系统一次性地解决了可扩展性，而不需要工程师额外的特别关注。
但是，随着Ignite的增长，社区对Ignite的发现机制进行重新审视，看它对扩展性有多大的影响，目标很明确，Ignite要扩展至上千个节点，就像目前上百个节点的时候一样。
这项工作花费了几个月的时间，很高兴地告诉大家，Ignite的2.5版本可以轻易地缩放到上千个节点，同时还具有强大的功能，下面看几个关键点。
大规模扩展性
Ignite2.5版本修改了两个组件来改进扩展性。第一个和上千个节点有关，而第二个和训练机器学习模型的方式有关，下面从第一个开始。
Apache Ignite 和 ZooKeeper结合
对了，借助于Apache Zookeeper，帮我们解决了上千个节点的扩展性问题，为什么呢？
Ignite默认的基于TCP/IP的发现机制，会将集群节点组织成一个环形拓扑结构，这有优点也有缺点。比如，在一个上百个节点的拓扑中，系统消息要遍历所有的节点要花费很多秒，从结果来说，很多必要事件的处理，比如新节点加入或者故障节点检测，就会非常影响系统的响应速度和性能，这样的话，如果是上千个节点，问题就会很大。
新的ZooKeeper 发现机制使用 ZooKeeper 作为单一的同步点，Ignite使用它来交换发现事件的消息，它解决了发现消息长期待处理的问题，从结果来说，可以使Ignite集群扩展至更大的规模。
按照传统，默认仍然是使用基于TCP/IP的发现机制，如果超过了300个节点，建议切换至基于Zookeeper的发现机制。
机器学习：基于分区的数据集
Ignite2.5的第二个关键特性是，在TB及PB级数据上，改进了机器学习模型的训练方法，基于分区的数据集，使我们更接近于无ETL概念的实现，这样Ignite就可以作为单一的存储，机器学习模型在其上可以在线地、不停地进行改进，而不需要Ignite和其他的存储之间不停地进行ETL数据交换。
遗传算法
Ignite的机器学习组件不断增加，在2.5版本中新接纳了遗传算法（GA）的贡献，通过模拟生物进化过程，有助于解决优化的问题。遗传算法非常善于对大量的复杂数据进行搜索。在现实世界中，遗传算法的应用场景包括汽车设计、计算机游戏、机器人、投资、交通/运输等等。
持续地自愈和一致性检查
众所周知，很多公司信任Ignite，将其部署在关键业务中，这样的话，Ignite甚至都没有权力“熄火”，应该有能力自动处理严重或者不可预见的情况，或者提供一种机制，使人们可以手工干预。
在Ignite的2.5版本中，已经开始实现一个持续自愈的概念，这意味着在生产中不管发生什么情况，Ignite都应该有能力容忍意外的故障，并保持持续运行。
SQL: 安全性和更快的数据加载
社区坚定于这样的目标，即让Ignite的SQL引擎与其他的著名的、成熟的SQL数据库无法区分。目的是什么呢？我们希望用户能容易地从关系数据库迁移到Ignite，这样用户还可以复用原有的能力。总的来说，Ignite在2.5版本中，新增了如下的功能：
通过COPY命令以及SQLAPI的流模型支持更快地进行数据加载；
长时间运行的事务监控和终止；
安全，Ignite支持CREATE USER、DROP USER、ALTER USER命令，来管理谁可以接入集群。
Spark DataFrame查询直接执行
Spark用户要欢呼了，简单来说，意味着从现在开始，就像在Ignite服务器端一样，Ignite也可以执行同样的DataFramesSQL查询，避免了不必要的数据移动，DataFrames查询的性能也会显著提升，爽吧!
DEB 和 RPM 包
最后，但并非不重要的是，对于Linux用户，以后可以从DEB和RPM仓库中直接安装Ignite的最新版本，具体可以看相关的帮助文档。
最后，更具体的优化和改进清单，可以看官方的版本发布说明。