性能保障策略.doc

_1.1.1 性能保障策略ECIF系统作为一个集中部署的业务应用系统，具有高并发、大数据量处理的特点，要在性能上满足整个系统的运行需要，除了主机、网络的处理能力之外，在各应用节点（包括应用服务器、WEB Server等）要从高性能集群技术、降低磁盘访问频率、流量控制、服务分配、交易分流各方面综合考虑，才能更好地保证系统高效、稳定地运行。性能设计主要依赖于两方面，其一软件本身限制，其二为硬件部分限制，宇信易诚公司结合多年银行从业经验，针对软件性能设计从产品设计初期一直延续到产品测试结束提供了完整的性能解决方案。1.1.1.1 产品高性能设计基于MDM产品经过多年积累，沉淀，针对性能问题已经过多年优化。且软件本身为可伸缩性系统，便于多项部署。从而提高系统本身性能。1.1.1.2 高效的数据算法针对每项数据算法，以及数据类型选择，经过严格测试，从优择选以最优算法，以及数据类型。且通过大量压力测试，支撑产品应用。1.1.1.3 良好的接口设计系统的整体接口经过严格设计，使接口设计为最优，避免大量创建类，保证整个产品最优运行。1.1.1.4 低耗的磁盘IO宇信易诚公司YC.ECIF产品中，针对所有磁盘IO操作采用最低限度使用IO策略，针对某些高频使用数据类型存储到缓存中，尽量避免针对磁盘IO操作。应用逻辑通过Cache技术直接访问装载在内存的配置数据，降低系统对磁盘的访问频率，提高系统的运行效率。1.1.1.5 细粒度的事务管理宇信易诚公司YC.ECIF产品中，数据访问的事务边界经过严格设计，粒度、事务完整性以及性能之间进行平衡，从而避免了长事务的增长导致的性能瓶颈。针对事务锁机制，宇信易诚ECIF系统通过高压测试调优，整体设计尽量避免锁等待瓶颈。1.1.1.6 产品的可伸缩性MDM产品设计和开发遵循了可伸缩性原则，保障ECIF系统可横向扩展，以持续提升性能。1.1.1.7 数据库性能设计1.1.1.7.1 索引控制在数据模型客户化设计中，索引经过严格筛选，避免某表多索引造成的写操作效率低下。1.1.1.7.2 SQL优化所有SQL语句均针对特定数据库（ORACLE，DB2）做充分优化并通过高并发、大数据量的压力测试。1.1.1.8 数据库高可用性设计1.1.1.8.1 分布式原则整体数据库采用分布式技术，从主机角度，以及应用角度等采取分布式技术，保障数据库高效运行。将数据库从主机角度采取分布式技术，结合广东农信实际情况使用数据库数据分布式技术，可保证在多个主机上运行数据库业务。1.1.1.8.2 读写分离原则读写分离原则，主要指在某节点数据库中写入数据，然后把写入的数据同步到多节点。而其它节点保障数据库读取应用。如此可将应用的负载分布在多个不同的数据库节点上面。如果写的数据库失败，可以找一个读的数据库来接管。1.1.1.8.3 垂直分割原则按照应用来分割，如应用1与应用2是可以独立出来的完全不同的应用，则把它独立出来，分割在两个不同的数据库服务器上，这样就实现了垂直分割。这种情况下，如果一个应用故障，就不会影响到其他应用。1.1.1.8.4 水平分割原则数据量的分割，如有一个用户表，可以按照一定规则，把用户表分割成两个表，再分布在两个不同的数据库中，当特定的用户访问数据库的时候，根据规则就可以知道它在哪个数据库中，然后访问该数据库即可。这种情况下，如果一个库失效，受影响的只是这个库存放的特定的用户。1.1.1.8.5 查询性能设计结合广东农信目前客户数量较大的情况，ECIF系统针对查询的问题将其按照用户需要、IT环境的设备条件等划分成一组问题域。下面将详细进行描述。1.1.1.8.5.1 制约条件ECIF系统内的查询功能一般会受以下几点因素的影响。 硬件硬件是决定系统性能的关键因素之一，包括应用服务器和数据库服务器的CPU、内存，磁盘IO性能等，随着系统用户并发数量的增加，CPU和磁盘IO的压力会相应加大，而对于JVM来说，一味加大内存堆容量，不一定会使系统吞吐能力线性加大，同时会加剧JVM垃圾回收的压力。对于广东农信ECIF系统这样庞大的系统来说，用户数量和并发数量非常之高，单台服务器模式不能满足性能方面的要求，应该考虑使用多台服务器进行逻辑加物理的系统部署方式。 网络广东农信网点分布较广，作为一个集中系统，从用户终端到服务器的网络连通状况是依据支行区域不同、机构层级不同是千差万别的。网络的延时直接加大了终端与服务器之间连接保持的时长，对服务器资源的占用有很大影响。 中间件性能开发系统采用的技术、使用系统运行的基础软件环境，包括应用服务器、数据库等。对查询性能也有不同程度的影响。 系统历史数据量系统实时数据库中保存数据的区间设计与性能紧密相关。数据量越大对数据查询的性能影响就越大。并且ECIF系统的数据结构的设计好坏对从大量数据中筛选必要数据的影响也是需要考虑的。1.1.1.8.5.2 优化策略 对大数据表做“表分区”、“索引分区”或“数据库分区”。 精心设计查询使用的索引，避免进行“全表扫描”。在考虑索引的字段的同时，也要考虑使用何种索引类型（聚集索引、B+树、位图等）。 精心准备查询使用SQL语句，特别要关注WHERE子句中条件表达式的写法，一些条件表达形式是无法使用索引的，例如like运算符。例外，条件表达式尽可能少地使用列函数和数据类型转换。写出高效SQL会涉及很多方面，这些知识在产品手册、书籍、互联网上都有较详细的介绍。这里强调的是，项目组有责任引导开发者明白开发高效SQL的意义，不断提升SQL应用水平，避免开发低效率的SQL。 尽可能使用ORACLE或DB2自有的性能优化策略。 活跃数据与历史存量数据分开。 尽可能避免排序，若不能避免排序必须有优化措施（如排序参数设计、排序临时空间、排序用到的索引、并行排序等）。 尽可能避免返回多行的结果集。 尽量避免使用相关子查询。 尽量避免使用Group子句。 如果JOIN操作的代价过大，可以考虑使用冗余列来避免JOIN操作。 将“性能调优”的重点放在查询时间长、资源消耗量大、使用又很频繁的SQL调用上。这时要准备多种