数据穿透和过滤的一些临时方案

原创
2013/12/30 18:45
阅读数 871

近两个月工作中主要应付的还是数据的穿透和过滤。比如系统a维护了一份比较重要的关系数据,某次活动,需要将系统b的一些数据穿透到系统a上,并且过滤出相应的数据。面对这种两大块不同来源数据merge的工作,似乎也没有很完美的解决方案。下面写点儿用到过的一些解决方案:

乍一看这种需求很简单,内存里做个merge不就可以了吗,如果涉及到分页、查询性能这些的时候,确实也不是那么容易做。

第一种最简单的方案,如果数据的变动不是很频繁,并且时间上也很宽裕,那可以采用打标的方式。在a系统的数据库中直接打标,标明这是要显示b相关的数据。这样就可以利用数据库来作筛选、分类,上层业务处理起来就方便多了。当然这种方式的前提是要方便打标,这里的方便指两方面,1、数据库要容易扩展,如果扩展个数据字段对系统影响很大,那建议就不要这样做了。2、数据的变化很少,如果数据动不动就更新,那么打标去标的操作会很频繁,这样会影响正常业务的性能,可能还会影响到数据的准确性。打标的方式一般都采用接消息去处理,这样的异步处理对系统的压力会小很多

由于我们的数据变动比较频繁,也不想别人的业务倾入到a系统中,所以并没有采取第一种方案。我们选择了第二种方案。一般大型网站都会用到缓存,缓存抗qps也很有用,所以,我们将这部分打标的信息直接放到缓存里,每次请求都走一次缓存,这样解决了问题,也减少了系统之间的耦合。但是这毕竟不是缓存正式的用法。而且,越到重要时刻,资源也越紧张,不会又那么多的机器拿来作分布式缓存。再后面的需求中,我们又采用了其他的办法。

第三种方案我们用bloom filter在内存里保有b系统的数据。这样做的坏处有很多,首先,这份数据有t加一的延迟,内存种的数据一般都是前一天晚上跑出来的离线数据,再次,bloom filter会有误判的情况发生,即使把容错率设置的再低,也无法达到百分之百的精准,最后,这种方式的开发成本很大。能用这种方式的前提是你们接受这些问题。但是这样做就把压力直接分担到了每台机器的内存中去,这样一来,一般万级的qps都没什么压力,虽然缓存也是用的内存(这中间存在一个资源的问题)。上个月,我们用bloom filter在内存中存了近1个亿的数据,大概使用了200兆的内存。这可能是用bloom filter的最大优点吧。

我们还会遇到一些需要实时同步内存的需求,比如b系统的数据会每半个小时变化一次,你每次查询又不可能实时去查b系统,这样只能每半个小时将数据同步一次。难点是a应用如果有200台机器,如何去同步。不可能200台同时去拉数据。和第二种方式有点相似,我们借助了hdfs这样的文件存储,由一台机器去拉全量数据,并压缩保存到存储系统,其他机器再从存储中去拿数据。这中间主要要做好任务同步的问题。

当然最理想的办法是可以有一套内存同步机制,可以随时同步内存,开销又很小。虽然tomcat、jboss这样的应用服务器都会有session同步的机制,但是成本还是有点儿高。也会又很多的内存推送框架,其实把这些框架的功能稍作组合就可以设计出比较合理的同步框架。



展开阅读全文
打赏
2
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
2
分享
返回顶部
顶部