系统部署方案与优化

1、系统部署方案与优化方案背景：目前部署在阿里云上的系统存在内存不够用，不定期的应用假死 问题。为了解决这些问题并能够很好的对系统的扩展性和可用性进行 配置。系统需要进行部署改造。为此提出改造方案。支付客户端 1支付客户端 N1、发送请求4、返回结果支付网关2、处理后发送3、处理后返回5、异步回调图：通讯过程Tomcat应用6、发送ActiveMQ消息服务器回调消息服务器数据库7、消息发送其中通讯虚线标识是一次连接， 但该连接为用完即关闭， 特点为连接目前的通讯过程主要有 2 中构成，分别如下表：序号通讯路径备注11234生成订单、主动查询、退款、取消订单2567付款通知详细的通讯过程如下图：时间

2、比较短。 图中实线标识该为一个连接， 但该连接具有连接时间长 的特点，一般是系统起来后进行连接，系统主要注销后关闭。其中步 骤 6 采用的连接池技术。从图中可以看出目前主要的瓶颈分别内存、 硬盘速度和大小、带宽（目前较好） 。分别讨论如下： 目前的内存的主要消耗对象为：内存消耗对象分析序号系统主要对象建议内存1Tomcat 应用服 务器目前没有使用缓存技术，主要是线程占用数和连接数占用相关的内存4G2ActiveX 消息服 务器主要是连接数和消息的存储（自带数据库存储引擎）4G3Mysql查询缓存4G4操作系统进程管理、调度10%4预留应急和升级20%结论：建议采用 16G 内存。因虚拟机内存

3、可以调整，在开始阶段可 以采用 8G 的内存（节省开支），支撑的数量高了调整为 16G. 关于 CPU,建议 4 核心 CPU 及以上。主要用来给 Mysql、java 使用 数据量来后，可以将 mysql 单独部署到独立的虚机上。 如果部署 mysql，建议硬盘 100G。不部署 mysql50G 即可。 本部署方案为迁移的方案，为计算优化需要的各个参数。优化方案系统的特点：数据增长量非常快，并且有在一定时间段比较集中 的特点。但是查询的量是比较少的，所有的操作基本上是以 32 位的 订单编号进行查询和修改。 下图为系统运行一段时间的后数据的冷热程度， 横轴为总量。 系统中 经常操作的数据往

4、往最新添加的数据从比例上可以看出占到的数据 量是比较小的。类似预授权的退款操作 热点数据 不建议采用分库分表的方案， 建议采用 noSql 中的 redis 技术和 mysql 共同处理。其中 Redis 采用 redis-storage技术，可以实现数据的快速 访问。redis-storage采用 google的 Leveldb 存储引擎，以下为 Leveldb 的相关情况： Leveldb 是一个 google 实现的非常高效的 kv 数据库， 目前的版本 1.2 能够支持十亿级别的数据量了。 在这个数量级别下 还有着非常高的性能，主要归功于它的良好的设计。特别是 LSM 算 法。 Lev

5、elDB 是单进程的服务，性能非常之高，在一台 4 个 Q6600 的 CPU 机器上，每秒钟写数据超过 40w，而随机读的性能每秒钟超 过 10w 。 实际使用情况：目前了解到国内某快递公司的核心骨干系统采用 redis-storage 进行查询和存储，日均处理单量大于 500 万（均为不同 的单号，平均 600 万），自上线后，运行较为稳定（ 1 年左右，总单量超过 20 亿条）。建议采用 Redis-storage技术，同时结合 mysql 做支付数据的离线分析 和备份。更改的结果为如下图，即增加一个 Redis-stroage的 nosql 数据库。利 用内存来进行加速。支付客户端 1支付客户端 N6、消息发送1、发送请求4、返回结果分离数据库1分离数据库2分离数据库N分支系统本方案的优点：性能上非常高， Redis-storage 非常适合该系统的特征，系统在单 量超高 10 亿单后，依然能够具有较