1.1.1性能保障策略
ECIF系统作为一个集中部署的业务应用系统,具有高并发、大数据量处理的特点,要在性能上满足整个系统的运行需要,除了主机、网络的处理能力之外,在各应用节点(包括应用服务器、WEB Server等)要从高性能集群技术、降低磁盘访问频率、流量控制、服务分配、交易分流各方面综合考虑,才能更好地保证系统高效、稳定地运行。
性能设计主要依赖于两方面,其一软件本身限制,其二为硬件部分限制,宇信易诚公司结合多年银行从业经验,针对软件性能设计从产品设计初期一直延续到产品测试结束提供了完整的性能解决
方案
气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载
。
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.2SQL优化
所有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水平分割原则
数据量的分割,如有一个用户表,可以按照一定
规则
编码规则下载淘宝规则下载天猫规则下载麻将竞赛规则pdf麻将竞赛规则pdf
,把用户表分割成两个表,再分布在两个不同的数据库中,当特定的用户访问数据库的时候,根据规则就可以知道它在哪个数据库中,然后访问该数据库即可。这种情况下,如果一个库失效,受影响的只是这个库存放的特定的用户。
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会涉
及很多方面,这些知识在产品手册、
书
关于书的成语关于读书的排比句社区图书漂流公约怎么写关于读书的小报汉书pdf
籍、互联网上都有较详细的介绍。
这里强调的是,项目组有责任引导开发者明白开发高效SQL的意义,不
断提升SQL应用水平,避免开发低效率的SQL。
尽可能使用ORACLE或DB2自有的性能优化策略。
活跃数据与历史存量数据分开。
尽可能避免排序,若不能避免排序必须有优化
措施
《全国民用建筑工程设计技术措施》规划•建筑•景观全国民用建筑工程设计技术措施》规划•建筑•景观软件质量保证措施下载工地伤害及预防措施下载关于贯彻落实的具体措施
(如排序参数设计、排序临时空间、排序用到的索引、并行排序等)。
尽可能避免返回多行的结果集。
尽量避免使用相关子查询。
尽量避免使用Group子句。
如果JOIN操作的代价过大,可以考虑使用冗余列来避免JOIN操作。
将“性能调优”的重点放在查询时间长、资源消耗量大、使用又很频繁的SQL调用上。这时要准备多种方案,反复测试比较,发掘和形成最优的解决方案。
使用应用级的数据缓存功能,例如一个极易使用的中、小型只读数据表,如果内存允许可以将数据预先装入内存,以后直接从内存中读取,从而避免数据库操作。
浙公网安备 33021202002483