社保行业推动业务数据大集中，多业务混合负载特点下关键系统如何实现数据强一致性？
全国社保行业有一个特点，省级社保和市级社保分开，是两套独立运行的民生系统，全国的社保联网尚未完成，无法实现数据共享。这种现状维持了很多年，始终没有得到改善。然而由于这几年经济一体化的影响，全国人口的流动性加剧，大多数的社会公民，都离了出生地，和户口所在地，四处打工。如果在异地他乡，想要享受医保待遇、社保待遇，那几乎是不可能的事，因此现在人社部正在着力推动各地省级大集中。我们知道银行系统，全国联网已实现多年，公民信息系统也已实现全国共享；所以社保系统全国联网，是时代发展的迫切要求。 那么：
1、社保数据数据大集中，要考虑哪些业务特点？
2、在基础架构层面，需要重点解决哪些技术层面问题，又是如何分步骤实施呢？
3、集中平台实现数据强一致性的架构方案有哪些？
4、集中平台的前端、后台服务器应该如何选型？
欢迎大家参与交流探讨！
10同行回答
一点浅见，抛砖引玉。
1、社保数据大集中，要考虑哪些业务特点？
社保省级大集中模式的基础是数据集中，不仅在物理上而且在逻辑上都要求最终建立统一的数据记录系统，以便于各业务模块之间、各地域之间统一有机地共享全部业务数据和人员信息。数据集中之后要求数据库服务器必须具备充分的扩展能力，以便保证业务发展时始终保持单一的数据映像，不改变IT架构的逻辑，不影响业务既有的规则与流程。
数据集中之后单一数据库的数据量将跳跃性地提升。数据服务器必须保证在超大数据量的情况下仍能保证业务处理的服务水平，特别是联机实时处理和批量数据汇总的服务水平。大集中后数据库服务器将同时为多种类型的业务应用提供数据服务，这些业务应用特点不尽相同，服务水平和响应时间要求都有差异。要求数据库服务器必须能够满意地保证所有业务类型的服务水平要求，同时提高有效的资源利用率。从业务特点来讲，大致有下面几种分类：
1. 联机事务处理（OLTP）：必须能够高效地处理省中心核心业务的联机处理，包括人力资源、劳动就业、社会保障五险业务、社保卡业务，信息交换业务和公共服务业务，等等。业务量参照覆盖人口数计算。
2. 批量处理（Batch）：月末/年末结算/测算(征缴费、养老待遇、拨/付款、查询统计，等等）。必须能够按照业务部门的要求在规定的时间窗内完成任务，保证业务的正常开展。例如：对于单项业务的月度征缴核算等任务要求在30分钟内完成；对于单项业务全省的月度并发核算要求在60分钟内完成；对于单项业务全省范围的查询统计要求在60分钟内完成。上述批处理业务包括夜间执行或白天与联机业务并发执行。
3. 查询与数据挖掘（OLAP): 针对各种业务主体建立数据模型并进行分析，支持宏观决策。
4. 数据流转：比如在生产库、交换库和决策库等数据资源之间进行数据抽取、转换、与加载等任务。
5. 数据维护：针对各种数据资源库进行数据加载、备份与恢复，在规定的时间窗内完成，并不影响业务的正常开展。覆盖全省的基础信息库、各个系统的业务经办库、公共服务信息库、各种交换信息库、数据仓库和主题分析库等等。必须提供足够的数据吞吐能力，高效地完成上述任务。
2、在基础架构层面，需要重点解决哪些技术层面问题，又是如何分步骤实施呢？
我们知道项目的需求主要分功能性和非功能性，其中功能性需求定义一个系统或组件的功能，也是一个系统需提供的功能及服务。功能需求会以非功能性需求（或是质量需求）为基础，后者会描述设计或实现时的限制条件（如：RAS、性能、安全、扩展性等等）。基础架构层与非功能性需求关系密切，且作为整个系统的基石，一方面需要满足关键业务类型（如：联机事务处理和批量处理）的性能问题和保证数据的强一致性；另一方面要提供安全、高可靠性的硬件架构，并有能力随着数据集中的逐渐深化而灵活扩展。
基础架构层面要充分考虑系统对批量业务的处理效率，比如有的客户因批量业务太过繁重，而不得不对服务水平进行妥协，给地市分组并按照不同日期/时间段分别进行结算。这种情况相信在省级大集中后会更为突出。
与OLTP有所不同，许多业务需要在固定时间段(月末、季末等）进行批量处理，有的可以在夜间进行，有的必须白天运行。这种类型的负载对I/O能要求大，通常它很难利用多线程去并发处理，因为大多数批处理不得不顺序执行以确保数据完整性。针对这种业务所需计算能力的预估需要特别注意，因为市场上常用的TPC-C值其实并不能对批量处理进行有效评估。基础架构的选择要考虑单CPU线程的处理能力、CPU缓存结构（以及各级缓存大小）、高性能的I/O处理系统、系统带宽等综合技术，来检验服务器处理某个量级的数据所消耗的单位时间。
社保大集中平台很多内容都需要安全和保密，其信息系统将分别在政务内网开展业务，和在政务外网向公众提供必要的服务，因此平台的安全级别要求很高。系统安全性也是该平台搭建过程中的一个重要考量指标。在基础架构设计上除了要考虑内外网设备的物理隔离，也要保证核心服务器本身具有最高的安全性。
最后，社保大集中平台的建设绝不是一蹴而就的，结合人社部信息中心对省级大集中的规划，可分两个步骤实施：1）初步建成省集中格局，基本完成省级基础信息库建设，实现地市基础数据和部分核心业务系统向省中心集中；2）全面实现社保业务系统在省级平台的大集中。分期实施给基础架构层带来新挑战：
1. 稳定的硬件扩展能力来承载从步骤一过渡到步骤二的建设目标，避免计算能力不足导致数据的拆分和应用重构
2. 保持基础架构前后的一致性，避免架构后期的复杂化
4、集中平台的前端、后台服务器应该如何选型？
社保大集中平台前端的展现层和业务接入层等没有数据实时一致性的要求，可以使用分布式的集群部署模式。建议选择性价比高，横向扩展能力强的服务器平台。这个选择的范围很广，如：Intel架构的x86服务器，IBM Power架构的PowerLinux和国产化的OpenPower，结合自身情况选择最适合平台。
后台的数据服务器则至关重要，对于核心的交易数据库系统如：参保人基础信息库/主数据库、业务生产库、一卡通数据库等，建议选择基于IBM大型主机（z Systems）的LinuxONE服务器。LinuxONE兼顾主机50多年传承的硬件高可靠性、安全性和扩展性，并与时俱进引入企业级Linux操作系统和兼容各种开放协议，使得主机的使用更平民化。 其他数据库系统，如决策分析、联网监测、共享交换等，可以选用小型机系统。
结合上述对第2个问题的阐述，LinuxONE服务器作为核心交易数据平台可以满足社保系统的瓶颈业务定期批量处理。LinuxONE具有特别明显的性能优势，这是由大型主机的技术架构特点决定的：强CPU能力（业界最高主频）、多级高Cache设计、强I/O能力和强资源调度能力。同时也可以满足在社保省级大集中不同建设步骤的平滑过渡，例如在阶段一采购部分资源的LinuxONE主机，而然在下一个建设阶段通过微码激活的方式升级所需要的性能，在这个过程中可以始终保持初始的基础架构，不会对原有的应用和数据造成影响。而在安全方面，LinuxONE更是获得高级别（EAL5+）的通用准则 (Common Criteria - CC) 安全认证。
收起看到这个话题觉得特别有感触。
第一，对于社保的业务来讲，从数据层面上来讲，要求实时强一致的并不是很多，只要保证数据在一定时间内保证最终的一致性就可以。
第二，全国的社保中心，如果按照市级划分，总数确实不少，但是每一个地市内基本只有一家，相对来讲业务集中性是比较强的。
第三，大部分的账户数据还是比较稳定，流动数据相对算是少数。
假设我们要实现全国数据的统一性，假设全国有10000个点，那么按照南北分区的话，每个数据中心平均的覆盖范围是5000个点。每一个点保留其当日交易数据，而南北数据中心保留账户的总账数据。晚上非正常工作时间所有覆盖的点跟数据中心总账系统对账，保持账户数据一致性。而交易历史数据保留在各个中心内。这样的话，数据中心内的数据节点的压力就放在了晚上，不会影响正常的日间业务。
第一步，我们基本实现南北的总账统一。
第二步，南北两个数据中心同步复制基本没有可能。但是南北两个数据中心之间可以实施异步复制，跨大区的业务保持一定时间的滞后。那么也就保证了整个数据的最终一致性要求。
以上是基于传统数据库技术的解决方案设想，不当的地方，请各位多多指教。
另外，聊一个完全有悖于传统架构的思路。
区块链技术，它最早源于比特币业务。总体思路是这样的：
全网节点平等，没有中心之区别。全网节点都保持一个核心总账数据的副本，也就是说每一个节点都是一个总账。
全网节点间通过区块分支算法，区块校验算法实现数据的最终一致性收敛。
节点之间通过P2P交易实现交易业务，通过加密算法保证交易的安全性。
交易业务通过广播算法到全网。
假设全国的社保中心都是网络节点中的一个分支节点，总账数据只是最核心的账户数据的抽象，所有票据及其他外围数据保留在各个中心。
总账数据通过算法全网实现收敛，当然需要一时间，不是实时的。但是这个时间会很短，小时级别。
每一个中心就是一个单独的节点，他会发布自己所有的交易信息，也会接受其他节点的交易信息。最终通过交易信息的审核保留有效的账务信息到总账链条上。
以上是对区块链技术应用到社保行业的一个简单设想，这种技术的实现需要业务层面的完全颠覆。也是对传统架构的完全颠覆。目前国际上有很多金融企业以及其他行业已经将这种技术应用到3.0版本。包括政府、教育、医疗等行业。
希望有一天，我们的医疗保障也能实现公正透明统一。有点跑题了哈，大家多见谅。
收起- 这些提法是按照一般银行的想法，作法思考的，没有了解现在全国社保信息化的实际情况，比如当前改革发展快，政策变化快，信息化建设就要跟上，就要调整。比如银行可以从全国大致的南北来分区域，但社保就无法实现。有些事情不能只从技术角度来考虑问题，因为技术不能解决一切问题，只能让事情做的更好，前提还是得用好相关技术。
- 这些提法是按照一般银行的想法，作法思考的，没有了解现在全国社保信息化的实际情况，比如当前改革发展快，政策变化快，信息化建设就要跟上，就要调整。比如银行可以从全国大致的南北来分区域，但社保就无法实现。有些事情不能只从技术角度来考虑问题，因为技术不能解决一切问题，只能让事情做的更好，前提还是得用好相关技术。
- 随着社保卡/医保卡、一卡通的引进，社保系统承载越来越多的金融功能。保证数据实时一致性和交易的完整性、实效性将是社保系统在业务处理上要注意的一个问题。 将区块链技术应用到社保行业无疑是一个创新，由此带来的变革不仅仅在技术层面，更是业务流程上。现在很多企业和IT厂商都在积极的探讨区块链技术，及其应用场景。IBM大型主机z Systems（包括LinuxONE）更是当仁不让，将全面支持区块链技术，同时与开源社区深度合作将区块链带入企业级应用。主机搭载业界最快的商业处理器芯片和高效的I/O系统，可以迅速处理数据队列。同时，通过芯片级的加密技术和硬件加密卡可以加速对多种加解密算法运算，其中包括SHA-256、SHA-512等。
- 说的有道理，不能按照南北分区域，这不符合社保业务的特点
随着劳动和社会保障制度的不断完善和社保信息化的深入，分散的社保信息需要进行整合，实现数据大统一。并且处在当今大数据的时代无法避免的要走数据统一整合的路线。
1、关键环节还是数据，只要数据不发生丢失情况，其他环节出现一些问题还是能够挽救的。但如果数据丢失了，则会带来灾难性的后果。在存储层面，数据大集中就好比把所有的鸡蛋都放在同一个篮子里，我们对篮子的保护工作要格外重视。对于数据的安全性应该是重中之重。可以采取本地镜像+同城、异地灾备模式，保护数据的安全及一致性。当前成熟的存储复制技术如EMC的SRDF、IBM的MGM（metro global mirror）均可实现数据的实时性、一致性保护，并可在主存储发生故障时，极短的时间切换到灾备存储上继续提供生产。
2、数据大集中后，由更高一层的信息管理部门来负责和管理数据，数据在使用安全和完整性两个方面都受到了严格的保护。
3、“小前端、大后台”的IT整合案例在众多行业中出现，这种IT建设模式带来3个好处：一是权利统一便于管理，二是执行效率提高，三是创新在统一的系统中变得更容易。所以在集中平台的前端、后台服务器选型方面个人感觉对于前端业务规模配置相应的X86集群作为前端服务器，对于后端有数据库的架构还是选会高性能、高稳定性的小型机，具体配置要根据具体的性能要求来选择。
- 后台的应用程序接口我们已经实现了虚拟化，后端数据库架构，我们是准备采用power架构的虚拟化集群来实现。不知是否有风险。
- 我们金保二期的数据库系统就是采用POWER架构的虚拟化技术来实现的，虽然地市级规模小，但技术架构是一样的，现在虚拟化技术是很成熟的，通过投入使用三年的实际使用情况看，主要风险还是实施和管理的规范化上。
- 这就更加坚定了我们使用Power 架构虚拟化的信心，你们铁岭社保既然已经使用了3年，能否详细说一下实施风险和管理风险到底有哪些？
- 我觉得只要前期规划好，考虑的全面些，实施方案需要跟厂商和实施方一起协商好，实施时就不会有太大问题。管理方面其实大多数还是基于传统的方式来做的，比如基于小型机的主机和数据库的问题处理。但这并没有达到我们的要求，应该利用好基于虚拟化的监控管理系统以及业务应用监控管理系统等手段提高管理能力才能减少各种风险。我们有部署TIVOLI监控系统（不用太多关注虚拟化管理系统）它能够对主机系统，存储系统，数据库系统做实时监控，但使用的不是太好，维保人员还是按照传统的方式来工作。这是个头痛的问题，如果大家都能提高一下管理工作的方式会更好 。
我前面的回答可能大家感觉文不对题，没有对提出的具体问题予以回答，下面我就几个具体问题给出我的理解和回答。但这里还是需要大家先对现有社保行业的业务特点有一定的了解，能够了解现有的情况如何？下一步的发展要求，或者人社部的要求等等吧。比如我理解的金保工程，就是国家层面真对社保行业的一个建设要求，由于社保的一些工作业务特点，以及一些历史问题的约束。我先说一下我参加人社部培训的一些理解，在人社部金保二期的建设规划要求中，有二个我认为重要内容：一个是省级大集中（不是全国大集中，也没有必要，这是不同于银行系统的）；二是达到国家等级保护的要求，就是专网三级，外网二级的要求。
所以对于大集中的理解，应该是省级大集中。记得在内蒙的培训就是这方面的内容，内蒙等几个省份已经部分实现了省级大集中，这是一个趋势，也是信息化建设发展的要求。
我们在建设金保二期过程中，由于当地的情况还达不到这样的要求，还是按照原来的以市级业务建设需求为主，因为我们在金保一期就是全市大集中的模式（当时主要的物理大集中，数据并没有做到完全集中），结合人社部的要求，我们二期建设过程中，提出了一体化的概念，就是要求能够满足人社系统所以业务需求的，实现各业务层的数据共享业务模式。为保障业务数据的准确性，还单独成立卡中心，卡信息数据的变更统一卡中心管理，业务数据变更由各业务管理部门各自管理，对中心各区域的访问，严格按照规范管理要求配置实施。虽然没有完全达到理想要求，但安全管理等方面还是向前走了一大步。全市参保数据更加准确，为向省级大集中做好了充分的准备。并且已经通过交换区将生产数据同步到省里，初步实现数据向省级集中的工作。
1.\"社保数据数据大集中，要考虑哪些业务特点？\"
如果要完全实现全省业务数据大集中，以我们的工作理解，首先要在全省做到政策统一，业务经办流程统一，技术管理和业务管理模式需要确定统一。这就要求全省的政策需要规范统一，业务经办流程需要重新梳理规范等等。
2.“在基础架构层面，需要重点解决哪些技术层面问题，又是如何分步骤实施呢？”
我的理解是应该看省级技术管理能力和资金投入能力来考虑，技术层面的问题，信息技术发展到现在应该不算是大问题了，主要看如何根据实际情况选择那种技术方案了。各有利弊，没有最好，只有更好。分步实施确是需要的，但需要规划好总的建设方案和分步实施方案，这部分还应该由省级和国家级的人社部门根据业务发展要求来研究，工作都需要做那些？数据都需要那些？我理解省级和国家级更多是 需要一些数据统计，数据挖掘类的宏观决策分析类工作。所以数据集中是首选。在各方面条件成熟后，再完全实现数据和物理设备的大集中。大集中的优势也是显而易见的，从信息安全管理要求，集中的投资资源和管理使用，集中的技术力量等等，但缺点是中心管理的压力增大，没有规范的管理理念和管理团队是无法保障的，现实的现状又缺乏技术管理力量，但完全交给第三方去管理也是不可行的，在日常的管理工作和等级保护测评中就会发现很多问题，不论是我们自己人员还是第三方服务人员，都需要规范的工作意识。
3.\"集中平台实现数据强一致性的架构方案有哪些？\"
我想如果能够实现完全的物理大集中，这个问题也就不能算个问题了，剩下的就是规划的问题了，这里我要说的是基础架构与业务应用的结合规划应该更重视，基础架构设计如果不能很好考虑实际业务应用需求，结果是很难想象的。同样业务应用无视基础架构环境条件，无节制提出自己的要求，也是很可怕的。
如果是先数据大集中，主要应该对数据的安全性，准确性做好规划考虑，并做好日常的管理就能够做的更好。
4.\"集中平台的前端、后台服务器应该如何选型？\"
这方面还需要结合各地的实际情况综合考虑，比如业务管理，技术管理是否有规范的管理办法。具体的情况，我们还是应该以人社部核心平台三版为中心，结合各地业务，重新设计规划比较好。
我目前能够理解到情况比较倾向于对应各地的前端服务器单独选择，具体可以选择基于X86架构的刀片服务器和VMWARE虚拟化技术相结合。可以从部署上面进行交叉部署来进一步提高业务应用的可用性和可靠性，以及后期发展管理的灵活性。
后台服务器，这个也是各自理解不同，选择也不同。我们当时选择时，有二个选择，一个是传统的正在使用的IBM的产品P系列服务器，另一个是基于ORACLE一体机。我们从管理使用的继续性等综合考虑，最终选择了IBM的P系列服务器，不过采用的是虚拟化来实现的。经过三年来的使用，总体效果还是不错的。
但做为省一级的应用，以我的解理，在后台数据库服务器方面，应该在根据不同的业务，在不同区域部署不同的服务器，以发挥其专长。比如在重要的生产区域，部署使用管理比较多的IBM服务器；在决策分析区域部署ORACLE一体机，oracle的一体机确实有它自己的特点。
再加上一些网络，业务应用的综合监控运维平台，就可以组成一套可行的建设管理方案。
还应该注重集成实施的管理，它是能否达到设计要求和管理要求的关键。这里特别需要提到等级保护的各项要求，如果能够从设计规划，到建设实施，再到运维管理，都按照等级保护的要求去实施，去管理，那么这个项目基本就没有什么问题或者不会有什么大问题。但实际情况可能差距较大，不论我们自己的工作人员还是第三方服务人员，目前普遍缺乏对等级保护要求的这些规范和意识，这些方面还有很长的路要走。
收起我觉得大家说的都有些道理，数据大集中，是国家社保政策层面的问题，涉及到人保部的顶层设计，不是一朝一夕就能解决的。
目前金保工程一期已经完成，一期工程只是解决了社保网络的宽广覆盖问题，即社保网络向下延伸。目前大多数的省份，已经可以完成社保网络向下延伸到乡镇社区，有的甚至延伸到了村组。
按理说社保网络的向下延伸和社保数据向上集中，应该上同步进行的。最起码说，延伸到一定阶段后，就要考虑数据的向上集中问题。经过这么多年的发展，我们注意到一个有趣的现象。就是网络延伸到是很快。但是数据集中问题却迟迟未见推进。可能是基于业务的技术风险考虑。我们作为技术人员应该多替领导分优，多提一些切实可行、稳妥可靠的技术方案。打消领导的顾虑。这个才是我们当前IT人士应该做的。
我们不可能一步到位，哪就分布实施，分阶段进行。12五规划我们只完成了网络覆盖问题，那么来个13五规划，我们就来实现数据的省级大集中。等14五规划，我们在进行全国的数据大集中还是可以的。
那么当下比较迫切的问题是如何实现省级数据大集中，有哪些切实可行的方案，有哪些成功的案例和经验可以借鉴。确保万无一失。哪个省敢第一个来吃这个螃蟹。我们非常想知道。也非常期待。
收起1. 社保数据与银行金融业务有点类似，日常处理侧重数据查询，并且涉及过去几年的历史数据，对存储性能和容量都有相当的挑战，如果实现全国社保数据大集中，需要强大的后台处理能力支持，目前大型银行一般使用大/中型机，高端小型机，结合商用数据库HA/集群，来满足后台处理能力的需求。
2. 基础架构层，由于涉及到大量的异构数据库的数据，应用/数据接口的统一，平台界面的统一，我觉得首先进行数据库层面数据归集和同步，然后中间件层面统一数据接入接口，然后实现前端接入平台的统一。
3. 数据强一致性可以通过异构存储的存储虚拟化技术来进行复制实现
4. 后台处理服务器可以选用IBM的高端power8小型机E880，前面依据处理业务量的大小可以选用S822等商用小型机+f5架构，也可以根据需要采用x86集群。
收起我也在社保行业工作多年，但在地级市，就谈谈我的理解吧，不当的地方，还请理解。
我觉得社保业的信息化发展比较被动，这也是它本身的特点等多方面的影响，比如受国家或者地方政策的影响；还有就是它的受众面广，开始主要是城镇职工，到包含城镇居民，再到城乡全体民众；又比如受社会快速发展，人们对各类业务以及便捷办理等的需求越来越高；还有象建设管理资金的影响等等吧。这些都不能简单理解象银行这样的行业去运行管理来要求；再比如业务经办，目前的主要业务都是在地级市，省级只是管理省本级的一部分业务，业务形式与市级是一样的，业务系统建设都是各自建设和管理。国家层面的人社部只是给一些指导性的要求，象金保工程，不是强制性的规范要求，配套的建设管理资金等等都不管，所以各自对这些指导性要求的理解也就各不相同，这些也多是历史遗留问题，需要根据各地的实际情况来安排来建设与管理。
从我们目前做的情况看（这个情况各地都有很大不同，一个省内都 不同，各省的不同情况就更大了），网络层在我们这里已经与人社部构成了五层网络结构（人社部--省人社--市人社--县区人社--乡镇），全部专网专线（内部网络）。我们从金保一期就实现了业务系统和数据完全集中在市本级--由一个市信息中心运行管理，县区没有自己的系统，只配合市中心管理县区网络接点；我们的业务经办也都通过县区接点，逐步延伸到社区和乡镇。具体到养老业务已经可以实现全国跨省转移办理；医保业务由于受政策的约束，目前还无法在全国范围内实现，现在也已经在省内部分实现了异地医疗自动就医结算办理业务。这些业务的开展，除了需要有一个健全的基础架构的支撑，还需要各级的政策和技术的配合与支持才能实现。
收起