先介绍学心理学的时候记住的两个把妹秘籍:
服务之间的一致性按照存储的ID和更新时间定时对比，也可以手动对比来保证。
对于现有的通知服务，因为业务方更新了本来会发消息通知我们更新缓存，更新了缓存再返回更细成功的消息给业务方。我说非要保留这个的话，我拿到通知更新的，我就直接返回，因为我的更新是ms秒级的，肯定比收消息再发消息这个通信过程快。
我提出了现有服务的问题：维护成本高，部署复杂，结构复杂，还有一些499的超时，我的搜索引擎都可以解决。因为我的内存支持全量索引数据和查询结果的缓存，所以接口直接调用，自己基本什么都不需要做。
好了，上面的都可以不看，因为被我们的技术大牛们批的体无完肤。下面是他们给出的考虑和建议：
首先，我最怕的问题，做与不做的问题。
到时候会支持两种调用模式，一种是RMIJava中，只要一个类extends了java.rmi.Remote
接下来就是怎么做的问题。
memecached。大家还提议做成插件形式的。
大家提出这个能够带来的一个很大的好处就是目前我们做的分库分表，采用搜索引擎的话，接口服务就不会受到影响。老大还提出：这个比较合适列表，和查询条件复杂的搜索，但是对于单个ID的搜索是不是还是走数据库更合适。这个需要等服务做出来之后测试来定。我个人倾向于都走搜索，因为保持一致，维护容易。我看过solrcloud的集群策略，集群之间的复制确实要比每个服务直接和数据库打交道出错率要高，所以我可以试着结合数据库直接数据交互，分片，加上高效的容错来做数据的一致性保证。会上忘了说搜索引擎的目前的搜索模型不合适媒资这样大多根据ID来查询的问题，到时候需要好好考虑。
，随手画的，等五一放假好好设计下logo[
如需转载，请注上我的原文链接： 谢谢哦~~
相关文章
精彩导读
热门资讯
关注我们
