读写分离技术在运营支撑系统中的应用.pdf
5墨值下载
2015，51（12）
1 引言
随着计算机、互联网和通信技术的不断发展，电信
运营商也正面临着从传统的基础网络运营商向现代的
综合信息服务提供商转型，支撑全业务经营的核心交易
系统
—
—运营支撑系统也随之不断地升级改造，日益表
现出多版本、松耦合、分布式等特点或趋势。在全业务
经营时代，电信运营商之间的差异化产品已经越来越
少，彼此的竞争已逐步演变为效率的竞争、流程的竞争、
服务的竞争
[1]
。如何以客户为中心，建立一套高性能、低
成本、开放式的运营支撑系统，不断提高服务开通效率、
不断提升服务质量、提升市场应变能力，是各大运营商
获取竞争优势的关键。
目前，运营支撑系统的基础设施层常用架构是小型
机、高端存储、Oracle 数据库的组合，其优点是集中、稳
定、高效，缺点是成本高昂、灵活性差、扩展能力弱。随
着信息技术的不断进步、企业的基础服务能力不断提
升，越来越多的企业开始探索更高效、低成本、稳健的解
决方案来逐步替换传统的、集中的、封闭的架构，读写分
离就是一个很好的解决方案。
读写分离一般指数据库层面，即在主数据库提供服
务的基础上，再增加一个或者多个提供只读服务的数据
库，这种方案本文称之为增加读库。广义上的读写分离
可以扩展到很多场景，只要是能够提供读服务的“数据
源”、能够分担主数据库中读操作压力的方案，都可以称
之为读写分离方案，例如数据缓存和搜索引擎等。
增加读库的解决方案与数据库高可用方案类似，都
需要解决数据复制、数据同步、数据一致性等问题。王
继刚等为保证电信设备持续运行，在嵌入式 Linux 系统
的高可用性设计方面展开了深入的研究
[2]
；林怀忠等在
数据的异步复制以及评价标准等方面展开了有效的研
究工作
[3]
。王延青等就分布式数据库复制过程中信息传
输量大、复制效率低、数据完备性难以保障等问题提出
读写分离技术在运营支撑系统中的应用
沙光华，陈 泳，张长江
SHA Guangh ua, CHEN Yong, ZHA NG Changjiang
中国电信股份有限公司上海分公司 企业信息化部，上海 200135
Departm ent of E nterprise Info rmatization, China Telecom Corporation Shanghai Branch, Shanghai 200135, China
SH A Guanghua, CHE N Yong, ZHANG Changjiang. Ap plication of read -write splitting technologies in op eration
support system. Computer Engineering and Applications, 2015, 51（12）：107-110.
Abstract：Read-write splitting technologies have been wi dely used in the information s ystem of large-scale enterprises.
Considering the actuality of core trading system in the traditional telecom operator, this paper applies new technologies,
including adding database for reading, data cache and search engi ne, into the system, in orde r to find the high performance,
high availability, and extensible solution. Experimental results show that t he read-write splitting technologies can greatly
improve the eff iciency of data reading and the overall performance of the system.
Key words：read-write splitting; data cache; search engine; operation support; enterprise informatization
摘 要：读写分离技术在很多大型企业的信息系统中得到了广泛的应用。结合传统电信运营商核心交易系统的架
构现状，通过增加读库、数据缓存、搜索引擎三种读写分离技术，设计了一种高性能、高可用、可扩展的数据层架构方
案。实验结果表明，读写分离可以极大地提升数据的读取性能以及整个系统的业务承载能力。
关键词：读写分离；数据缓存；搜索引擎；运营支撑；企业信息化
文献标志码：A 中图分类号：TP39 1 doi：10.3778/j.issn.10 02-8331.1406-0152
作者简介：沙光华（1964—），男，高级工程师，资深业务分析师，研究领域为数据层架构、应用层架构等；陈泳（1970—），女，资深
业务分析师，研究领域为业务与运营支撑系统等；张长江（1982—），男，研发工程师，研究领域为运营支撑系统、企业数据
应用等。E- mail：z cj_shtel@126.com
收稿日期：2014-06-11 修回日期：2014-09-23 文章编号：1002-8331（2015）12-0107-04
CNKI 网络优先出版：2014-12-22, http://www.cnki.net/kcms/detail/11.2127.TP.20141222.1041.022.html
C omputer Engineering and Applications 计算机工程与应用
107
C omputer Engineering and Applications 计算机工程与应用
2015，51（12）
了一种“拉推式”的解决方案
[4]
。倪泳智等基于一主多从
架构，使用异步分发技术实现了一种基于虚拟日志的高
可用数据复制方案
[5]
。蔡亮等根据组通信同步复制机
制，提出一种基于写操作集的数据库多主同步复制模
型，能解决异步复制带来的延迟问题
[6]
。
数据缓存的研究热点主要集中在分布式环境下如
何提高数据一致性、利用率、命中率和减少网络通信成
本等。黄世能等采用了多种不同的方法来解决分布式
缓存的一致性问题，并提出了一种虚缓存节点的概念
[7]
。
谢骋超等基于哈希 表 设 计 了 一 套 分 布 式 缓 存 系 统
[8]
。
李文中等在分布式缓存的优化部署算法上进行了深入
的研究
[9]
。蔡涛等对云应用的特性，设计了基于影响因
子的缓存策略
[10]
。
搜索引擎是为了解决互联网信息泛滥而出现的，其
主要应用于互联网行业，在非互联网行业却鲜有应用。
必须要结合应用场景去选择或定制自己的搜索引擎，因
为没有一个搜索引擎能完全满足所有用户不同类别的
需求
[11]
。耿会东等创新地设计了一个面向物理实体的
搜索引擎
[12]
，就是一个非常不错的尝试。汤羽等将搜索
引擎与大数据结合起来，基于 Hadoop 分布式文件系统
的开源架构与多级索引表的海量数据检索算法进行了
深入的研究
[13]
。Ap ache Lucene 是一款非常优秀的开源
搜索引擎工具，已经广泛应用于信息搜索领域。但是，
在针对不同数据源和应用场景时，Lucene 提供的功能又
显得不够完善，需要做二次开发。宋佳等基于 Lucene
实现了 一个增强 型的全文 搜索引擎
[14]
，匡振国等 基于
Lucene 设计了一个影片搜索引擎
[15]
，本文应用的搜索引
擎也是基于 Lucene 做的定制开发。
读写分离技术已经在大型互联网企业中得到了充
分的应用
[16]
，而在传统运营商的核心交易系统中却很少
应用，这主要是因为传统运营商与互联网企业的业务场
景迥然不同。本文以中国电信上海公司运营支撑系统
的业务应用为背景，研究将这三种技术应用到该系统中
的可行性以及由此带来的价值，为其他生产系统提供标
准性、规范性的参考依据。
2 传统架构现状
中 国 电 信 集 团 规 范 CTG-MBOS S（China Telecom
Group-Management/Business/Operation Support System）
是对中国电信企业信息化工作的系统概括和全面论述。
根据 CTG-MBOSS 规范，运营支撑系统包括服务开通、
运营支撑、服务保障等专业领域，旨在建设一个覆盖全
业务、全网络的运维支撑平台。
在运营支撑系统的传统架构中，数据库系统既承载
了 在 线 处 理 的 OLT P（On-Line Transac tion Processing，
联机事务处理）业务，又承载了一部分分析运算的 OLAP
（On-Line Analytical Processing，联 机 分析处理）业 务，
而最消耗资源的往往是那些 OLAP 业务。
数据库节点一般配置都是一个主数据库、一个备用
数据库，备用数据库一般只作备份、容灾切换之用。通
常情况下，都是主数据库提供服务，且是读写混合的，而
其中读操作远远多于写操作，平均的读写比例大概在
5∶1 左右，业务高峰时期的读写比例达到 10∶1，主数据
库读写操作的压力都非常大，导致整个系统的业务承载
能力存在瓶颈。
在数据层进行读写分离的架构部署，可以最大限度
地释放主数据库的 OLTP 处理能力，降低读操作对数据
库的冲击，加速数据的读取性能等，从而提高整个系统
的业务承载能力。
3 基于读写分离的新架构
3.1 增加读库
增加读库是在保留主数据库提供服务的基础上，增
加了一个或者多个数据库提供只读服务，用以分担主库
上读的压力。增加读库需要解决从主库到读库的数据
复制问题，数据库系统一般都会提供数据复制功能，但
是在实际的生产运营过程中，还需要考虑数据复制的时
延问题，以及复制过程中数据转换、过滤条件的支持等
问题。图 1 所示即为增加读库方案的系统架构图，其中
的虚线部分就是新增加的读库。
数据库系统提供的数据复制功能是相对有限的，在
一些场景下（例如主库有大量更新操作时）复制会有非
常明显的延迟。复制延迟将导致读库的数据在短时间
内与主库不完全一致，这时候读库提供的读服务就不是
最新的，这对于一些实时性要求高的应用场景是比较致
命的。常用的应对策略是，对数据复制延迟较为敏感
的、重要的读操作通过主库来进行，当然这需要上层应
用配合改造。
需要指出的 是，增 加读库会对应用层 产生一些影
响，例如写操作需要走主库、事务中的读需要走主库、重
要的读需要走主库、常规的读走读库等等。因此，应用
层需要根据不同的场景来选择不同的数据库源。
3.2 数据缓存
很多大型生产交易系统中，都会用到缓存机制。缓
存早期应用于 CPU、硬盘等计算机硬件中，本文讨论的
应用服务器 n
应用服务器 2
应用服务器 1
应用
程序
写操作
读操作
数据库服务器（主库）
数据库
复制
数据库服务器（读库）
数据库
图 1 增加读库方案架构示意图
108
of 4
5墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论