系统部署方案与优化
方案背景：
目前部署在阿里云上的系统存在内存不够用，不定期的应用假死

问题。为了解决这些问题并能够很好的对系统的扩展性和可用性进
行配置。系统需要进行部署改造。为此提出改造方案。

目前的通讯过程主要有 2 中构成，分别如下表：
序号 通讯路径 备注
1
○1○ ○2○ ○3○ ○4

生成订单、主动查询

退款、取消订单
2
○5○ ○6○ ○7

付款通知

详细的通讯过程如下图：

1、发送请求
4、返回结果

2、处理后发送
3、处理后返回
5、异步回调

图：通讯过程

7、消息发送
6、发送
回调消息

其中通讯虚线标识是一次连接，但该连接为用完即关闭，特点为连

支付网关
ActiveMQ消息 服务器 数据库 Tomcat应用
服务器

支付客户端1
支付客户端N
支付宝
财付通

、
接时间比较短。图中实线标识该为一个连接，但该连接具有连接时
间长的特点，一般是系统起来后进行连接，系统主要注销后关闭。
其中步骤 6 采用的连接池技术。从图中可以看出目前主要的瓶颈分
别内存、硬盘速度和大小、带宽（目前较好）。

分别讨论如下：
目前的内存的主要消耗对象为：
内存消耗对象分析

序号 系统 主要对象 建议内存
1
Tomcat 应用服 务器 目前没有使用缓存技术，主要是线程
占用数和连接数占用相关的内存
4G

2
ActiveX 消息
服务器
主要是连接数和消息的存储（自带数

据库存储引擎）
4G

3
Mysql 查询缓存 4G
4
操作系统 进程管理、调度
10%

4
预留 应急和升级
20%

结论：建议采用 16G 内存。因虚拟机内存可以调整，在开始阶段可
以采用 8G 的内存（节省开支），支撑的数量高了调整为 16G.
关于 CPU,建议 4 核心 CPU 及以上。主要用来给 Mysql、java 使用。
数据量来后，可以将 mysql 单独部署到独立的虚机上。

如果部署 mysql，建议硬盘 100G。不部署 mysql50G 即可。
本部署方案为迁移的方案，为计算优化需要的各个参数。
优化方案
系统的特点：数据增长量非常快，并且有在一定时间段比较集中
的特点。但是查询的量是比较少的，所有的操作基本上是以 32 位的
订单编号进行查询和修改。

下图为系统运行一段时间的后数据的冷热程度，横轴为总量。系统
中经常操作的数据往往最新添加的数据从比例上可以看出占到的数
据量是比较小的。

类似预授权的
退款操作
热点数据

不建议采用分库分表的方案，建议采用 noSql 中的 redis 技术和
mysql 共同处理。其中 Redis 采用 redis-storage 技术，可以实现数据
的快速访问。redis-storage 采用 google 的 Leveldb 存储引擎，以下为
Leveldb 的相关情况： Leveldb 是一个 google 实现的非常高效的 kv
数据库，目前的版本 1.2 能够支持十亿级别的数据量了。 在这个数
量级别下还有着非常高的性能，主要归功于它的良好的设计。特别
是 LSM 算法。LevelDB
是单进程的服务，性能非常之高，在一台

4 个 Q6600 的 CPU 机器上，每秒钟写数据超过 40w，而随机读的性
能每秒钟超过 10w。

实际使用情况：目前了解到国内某快递公司的核心骨干系统采用
redis-storage 进行查询和存储，日均处理单量大于 500 万（均为不同

的单号，平均 600 万），自上线后，运行较为稳定（1 年左右，总单
量超过 20 亿条）。
建议采用 Redis-storage 技术，同时结合 mysql 做支付数据的离线分
析和备份。

更改的结果为如下图，即增加一个 Redis-stroage 的 nosql 数据库。
利用内存来进行加速。

1、发送请求
4、返回结果
6、消息发送

2、处理后发送
2、处理后返回
5、发送

回调消息

骨干系统

本方案的优点：
性能上非常高，Redis-storage 非常适合该系统的特征，系统在单
量超高 10 亿单后，依然能够具有较好的性能。

工程上的好处：本方案没有采用复杂的分表和分库，结构简单，
减少了程序的复杂性。可以先完成程序和 redis-storage 部分，后续
进行分离数据的功能编写。

分支系统

支付网关
ActiveMQ消息 服务器 分离数据 库1 Tomcat应用
服务器

支付客户端1
支付客户端N
支付宝
财付通
Redis-storage

分离数据
库2
分离数据

库N