并不总是能为远程工作者提供最好的服务

3、处理逻辑APP化解决高可配问题

由于报警处理逻辑复杂多变，所以报警处理集群的每一个处理节点都设计成一个报警处理APP容器，一个报警处理APP是指一个逻辑功能部件，用来处理某一类业务，比如进维护期、事件丰富、事件通知等等，APP容器具有以下特点：

•  报警处理APP采用热拔插方式。当APP数量很大导致，容器资源不够时，可以通过水平扩张集群节点解决；
•  报警处理APP的开发可以用系统提供的脚本开发，也可以用scala或java开发，对于脚本开发的APP，容器采用Antlr进行语法分析，翻译成Java代码，然后用Java动态编译技术编译成字节码运行，以提高处理速度；
•  优雅停启：当更新一个APP时，它正在处理的数据会处理完毕才自动停止，需要马上处理的数据由新的APP处理，即新老APP可能有一个重叠的时间在同时运行。

报警处理APP有以下类型：

•  流APP：在每一个处理节点上都运行的APP，处理实时报警，如果一个报警符合此APP的条件，则运行此APP逻辑；
•  调度型批APP：由报警处理集群的调度引擎将这类APP分布在不同的节点上运行，每个APP只有一个实例，定时从报警库中取一批特定的报警进行处理。
•  订阅型批APP：由报警处理集群的调度引擎将这类APP分布在不同的节点上运行，每APP只有一个实例，从流APP或调度型批APP订阅数据，进行统一集中处理；
•  广播型批APP：在每一个节点都运行的批处理APP，事件来源为某个调度型APP分配的数据，起到分布式处理的作用；
•  Restful APP：动态生成Restful接口的APP，以便访问APP的内部数据。

4、 Apache Ignite分布式存储解决存储高性能问题

由于报警数据量大报警会不时产生风暴、每一条告警处理过程中会大量的读写报警库，所以需要一个分布式内存数据库作为报警库。

因为常见以往的如MySQL、Oracle磁盘型关系数据库，在这样高频度访问和复杂逻辑处理下，无法满足监控报警系统高并发读写的需求，而采用单机版的内存数据库，在报警风暴的时候，同样会产生报警库瘫痪的问题。

在G行新一代报警系统开发和建设时，采用分布式内存数据库ApacheIgnite存储告警，可以将访问和逻辑处理分离并且在多节点内存中进行并行处理，所以性能完全能满足实际需求。

 

不过，虽然索引可以加快查询速度，提高 MySQL 的处理性能，但是过多地使用索引也会造成以下弊端：

• 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
• 除了数据表占数据空间之外，每一个索引还要占一定的物理空间。如果要建立聚簇索引，那么需要的空间就会更大。
• 当对表中的数据进行增加、删除和修改的时候，索引也要动态地维护，这样就降低了数据的维护速度。

注意：索引可以在一些情况下加速查询，但是在某些情况下，会降低效率。

索引只是提高效率的一个因素，因此在建立索引的时候应该遵循以下原则：

• 在经常需要搜索的列上建立索引，可以加快搜索的速度。
• 在作为主键的列上创建索引，强制该列的唯一性，并组织表中数据的排列结构。
• 在经常使用表连接的列上创建索引，这些列主要是一些外键，可以加快表连接的速度。
• 在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，所以其指定的范围是连续的。
• 在经常需要排序的列上创建索引，因为索引已经排序，所以查询时可以利用索引的排序，加快排序查询。
• 在经常使用 WHERE 子句的列上创建索引，加快条件的判断速度。

现在大家知道索引为啥能这么快了吧，其实就是一句话，通过索引的结构最大化的减少数据库的IO次数，毕竟，一次IO的时间真的是太久了。。。

总结

就面试而言很多知识其实我们可以很容易就掌握了，但是要以学习为目的，你会发现很多东西我们得深入到计算机基础上才能发现其中奥秘，很多人问我怎么记住这么多东西，其实学习本身就是一个很无奈的东西，既然我们不能不学那为啥不好好学?去学会享受呢?最近我也在恶补基础，后面我会开始更新计算机基础和网络相关的知识的。

（编辑：衡水站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!