数据泵推数据到memoryDB,各客户端从memoryDB取数据到本地cache,页面调用本地cache

发展过程

为什么客户端不直接调memorydb的数据,是因为有时候网络不稳定,会导致前台无用,和网络传输数据比较大.

 

这里面有很多细节,主要用到了线程控制,和异步列队,虽然用了很多机器,但可以让搜索不用读数据库.

 

数据泵方面

要推大量数据,所以先要拆分数据请求,比如以城市为单位,以姓为单位,再分线程推到列队表里面去,然后分布式一堆服务器从列队表里面拿数据请求,去订阅数据库里面搜数据,拼数据,再写到memorydb里面去,memorydb也是个组集成服务,这里有个密集往memorydb写数据的问题,要考虑memorydb的性能.

另外,如何统计所有服务器把memorydb的内容都更新完,也是一个工作,需要做一些标记,开一些线程去统计,都终要有个变更来判定一次数据更新操作是否完成.

 

IIS端或其它客户端,开线程时时访问这个更新标志,如果出现更新,就把数据下载到本地,所有数据应该小于3G.

问题1

3G的数据很大,多台web服务器一次向几台memorydb服务器请求3G的数据,会网络阻塞,所以要有足够多的memorydb服务器来分网络流量,这么多机器来分3G的数据,有点浪费.

 

现在有了新问题

因为memorydb数据分布无法控制,有很多逻辑需要完整数据才能运行,所以memorydb某一台机器出现故障,就会使一个业务逻辑跑不起来

我觉得应该memorydb进行备分,现在的应用的思路是进行数据库的落地,当 memorydb有问题时,去数据库搜索,不过我想,数据库可以无法应付高搜索量而崩溃.