二级共享内存集群实现
一.设计目标随着应用的越来越复杂，对数据同步和存储的要求越来越多，有时候我们面对大量复杂的数据加载和数据同步代价，尤其是如果单服务器无法承载大量应用数据的时候，我们如何可以实现动态扩展服务器已达到负载均衡的目标。此设计只针对平均分布应用数据而建立，上不考虑特例服务器集群结构。考虑到目前的需求，参考了目前流行的几种中间件模式，比如ICE, TAO和Tuxedo，由于本人有一些ICE和TAO的实际商业化经验，所以觉得纯用中间件无法解决多级数据缓冲的问题，而且中间件部署复杂，应用中的最大管理问题是学习成本较为高昂，而我们的实际应用并不用到太多中间件的高级功能。所以暂不考虑中间件。用最简单的实现去解决需要处理的需求。此设计主要解决以下几个问题。（1） 让应用剥离对IO数据更新的管理，应用只专注于与其自己用的共享内存的管理，不在负责共享内存新数据的加载和存储。（2） 提供专门的共享内存维护进程（以下简称此进程为watch），负责用于同步上级数据源，（3） 提供可以动态伸缩的多服务器架构。（4） 提供可管理动态伸缩的服务器监控者（以下简称Grid Proxy）,负责可配置动态的服务器增减。二.设计实现原理这是一个具体实现的最小单元此单元可以平行扩展服务器可以是多台平行扩展，这里应用程序A对数据的依赖全部从共享内存A获得，这里的应用共享内存可以是多个。可以是一个M对N的关系。目前的结构只针对读多写少的情况，写多读少的情况，需要对Wacth有一些特殊的设计，这里暂不论述。对于此架构，应用程序并不是它管理的内同，应用逻辑和此架构是相对独立的。此架构对于共享内存，只做同步管理。同步规则是定时memcopy同步远程的数据源中的对象。达到同步数据的目的。同步规则，在Wacth里面实现。Watch根据同步配置文件，从远端数据源中获得相应的自己感兴趣的数据，在获得数据源数据的时候，只存在本进程的内存空间，当同步完成，再统一刷到共享内存A中完成数据同步。Grid Proxy是负责监控每个Watch的监控状态。当新的Watch启动的时候，会自动连接到Grid Proxy，GridProxy收到新Watch注册信息，会通知所有已注册的Watch，这些Watch会根据逻辑重新加载自己感兴趣的数据，达到自动数据平衡的能力。如果一个Watch因为某些原因离线或者挂掉，Grid Proxy也会通知所有的Watch知道，从而达到数据均衡分布。这样做，当数据源宕机，或者本地宕机，都可以迅速恢复，保证数据最大可用性。二级缓冲的最大作用是减少IO通讯量。 三.设计需要的进程以及进程内部结构共享内存，对于次架构，共享内存只是一个二进制块，对于C++和C而言，我只要知道共享内存单元的大小和count即可，那么Sizeof(T)*Count 便可获得当前共享内存的大小，这些完全可以作为Watch的配置文件。这样可以管理若干个共享内存的同步操作。( linux下考虑每个操作子进程操作)。实际每个子进程，对应一个同步规则。可以从远端数据源中获得当前共享内存需要的数据，这部分数据被当前子进程new出来，在本地内存中管理，当所有感兴趣的内存同步完成后，再一次性memcopy到共享内存中去，这次拷贝需要进行文件锁。拷贝完成后，逻辑进程再进行访问，因为memcopy远比获取同步修改要快的多，所以同步时间比较短。具体等待实测数据附证。GridProxy是一个完整的监控Watch的工具，它的主要工作是监控是否所有的Watch都在健康工作，同时如果有新的Watch添加进集群，那么会通知其他所有的Watch，稀释或者浓缩共享数据。
具体实现代码，将在PSS0.92版本发布的时候发布样例代码。有兴趣的请关注PSS的SVN。
应用程序 为啥不和 watch 合一块呢， 同一个进程就不用共享内存了， watch 弄成个.so 也应该比较通用。反正数据远端也有本地宕就宕呗 已经实现，有兴趣可以从SVN下载。
页:
[1]