系统部署方案与优化
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
20%
结论：建议采用16G内存。因虚拟机内存可以调整，在开始阶段可以采用8G的内存（节省开支），支撑的数量高了调整为16G.
关于CPU,建议4核心CPU及以上。主要用来给Mysql、java使用。数据量来后，可以将mysql单独部署到独立的虚机上。
如果部署mysql，建议硬盘100G。不部署mysql50G即可。
系统部署方案与优化
方案背景：
目前部署在阿里云上的系统存在内存不够用，不定期的应用假死问题。为了解决这些问题并能够很好的对系统的扩展性和可用性进行配置。系统需要进行部署改造。为此提出改造方案。
目前的通讯过程主要有2中构成，分别如下表：
序号
通讯路径
备注
1
生成订单、主动查询、退款、取消订单
2
付款通知
详细的通讯过程如下图：
本部署方案为迁移的方案，为计算优化需要的各个参数。
优化方案
系统的特点：数据增长量非常快，并且有在一定时间段比较集中的特点。但是查询的量是比较少的，所有的操作基本上是以32位的订单编号进行查询和修改。
下图为系统运行一段时间的后数据的冷热程度，横轴为总量。系统中经常操作的数据往往最新添加的数据从比例上可以看出占到的数据量是比较小的。
实际使用情况：目前了解到国内某快递公司的核心骨干系统采用redis-storage进行查询和存储，日均处理单量大于500万（均为不同的单号，平均600万），自上线后，运行较为稳定（1年左右，总单量超过20亿条）。
建议采用Redis-storage技术，同时结合mysql做支付数据的离线分析和备份。
更改的结果为如下图，即增加一个Redis-stroage的nosql数据库。利用内存来进行加速。
图：通讯过程
其中通讯虚线标识是一次连接，但该连接为用完即关闭，特点为连接时间比较短。图中实线标识该为一个连接，但该连接具有连接时间长的特点，一般是系统起来后进行连接，系统主要注销后关闭。其中步骤6采用的连接池技术。从图中可以看出目前主要的瓶颈分别内存、硬盘速度和大小、带宽（目前较好）。
分别讨论如下：
本方案的优点：
性能上非常高，Redis-storage非常适合该系统的特征，系统在单量超高10亿单后，依然能够具有较好的性能。
工程上的好处：本方案没有采用复杂的分表和分库，结构简单，减少了程序的复杂性。可以先完成程序和redis-storage部分，后续进行分离数据的功能编写。
不建议采用分库分表的方案，建议采用noSql中的redis技术和mysql共同处理。其中Redis采用redis-storage技术，可以实现数据的快速访问。redis-storage采用google的Leveldb存储引擎，以下为Leveldb的相关情况：Leveldb是一个google实现的非常高效的kv数据库，目前的版本1.2能够支持十亿级别的数据量了。在这个数量级别下还有着非常高的性能，主要归功于它的良好的设计。特别是LSM算法。LevelDB是单进程的服务，性能非常之高，在一台4个Q6600的CPU机器上，每秒钟写数据超过40w，而随机读的性能每秒钟超过10w。
目前的内存的主要消耗对象为：
内存消耗对象分析
序号
系统
主要对象
建议内存
1
Tomcat应用服务器
目前没有使用缓存技术，主要是线程占用数和连接数占用相关的内存
4G
2
ActiveX消息服务器
主要是连接数和消息的存储（自带数据库存储引擎）
Βιβλιοθήκη Baidu4G
3
Mysql
查询缓存
4G
4
操作系统
进程管理、调度
10%
4
预留
应急和升级
结论：建议采用16G内存。因虚拟机内存可以调整，在开始阶段可以采用8G的内存（节省开支），支撑的数量高了调整为16G.
关于CPU,建议4核心CPU及以上。主要用来给Mysql、java使用。数据量来后，可以将mysql单独部署到独立的虚机上。
如果部署mysql，建议硬盘100G。不部署mysql50G即可。
系统部署方案与优化
方案背景：
目前部署在阿里云上的系统存在内存不够用，不定期的应用假死问题。为了解决这些问题并能够很好的对系统的扩展性和可用性进行配置。系统需要进行部署改造。为此提出改造方案。
目前的通讯过程主要有2中构成，分别如下表：
序号
通讯路径
备注
1
生成订单、主动查询、退款、取消订单
2
付款通知
详细的通讯过程如下图：
本部署方案为迁移的方案，为计算优化需要的各个参数。
优化方案
系统的特点：数据增长量非常快，并且有在一定时间段比较集中的特点。但是查询的量是比较少的，所有的操作基本上是以32位的订单编号进行查询和修改。
下图为系统运行一段时间的后数据的冷热程度，横轴为总量。系统中经常操作的数据往往最新添加的数据从比例上可以看出占到的数据量是比较小的。
实际使用情况：目前了解到国内某快递公司的核心骨干系统采用redis-storage进行查询和存储，日均处理单量大于500万（均为不同的单号，平均600万），自上线后，运行较为稳定（1年左右，总单量超过20亿条）。
建议采用Redis-storage技术，同时结合mysql做支付数据的离线分析和备份。
更改的结果为如下图，即增加一个Redis-stroage的nosql数据库。利用内存来进行加速。
图：通讯过程
其中通讯虚线标识是一次连接，但该连接为用完即关闭，特点为连接时间比较短。图中实线标识该为一个连接，但该连接具有连接时间长的特点，一般是系统起来后进行连接，系统主要注销后关闭。其中步骤6采用的连接池技术。从图中可以看出目前主要的瓶颈分别内存、硬盘速度和大小、带宽（目前较好）。
分别讨论如下：
本方案的优点：
性能上非常高，Redis-storage非常适合该系统的特征，系统在单量超高10亿单后，依然能够具有较好的性能。
工程上的好处：本方案没有采用复杂的分表和分库，结构简单，减少了程序的复杂性。可以先完成程序和redis-storage部分，后续进行分离数据的功能编写。
不建议采用分库分表的方案，建议采用noSql中的redis技术和mysql共同处理。其中Redis采用redis-storage技术，可以实现数据的快速访问。redis-storage采用google的Leveldb存储引擎，以下为Leveldb的相关情况：Leveldb是一个google实现的非常高效的kv数据库，目前的版本1.2能够支持十亿级别的数据量了。在这个数量级别下还有着非常高的性能，主要归功于它的良好的设计。特别是LSM算法。LevelDB是单进程的服务，性能非常之高，在一台4个Q6600的CPU机器上，每秒钟写数据超过40w，而随机读的性能每秒钟超过10w。
目前的内存的主要消耗对象为：
内存消耗对象分析
序号
系统
主要对象
建议内存
1
Tomcat应用服务器
目前没有使用缓存技术，主要是线程占用数和连接数占用相关的内存
4G
2
ActiveX消息服务器
主要是连接数和消息的存储（自带数据库存储引擎）
Βιβλιοθήκη Baidu4G
3
Mysql
查询缓存
4G
4
操作系统
进程管理、调度
10%
4
预留
应急和升级