DataServer 需要 访问 ManagerServer 的设备基础信息,设备型号信息,且访问频率比较频繁(突发性 6 次查询每 10 秒)。但基本(设备和型号 信息)不会做太多的变更
1. 考虑保持 DataServer 的独立性,使其运行不依赖 ManagerServer
2. 考虑一定的性能扩展空间
3. 目前是使用 guava 在 DataServer 中做了一层 cache ,缓存 5 分钟
1. 方案一:考虑在 DataServer 中做一个本地缓存?然后 ManagerServer 中修改后异步通知 DataServer 进行变更。
2. 方案二:在 ManagerServer 中做本地缓存
3. 方案三:ManagerServer 缓存给 Reids ,DataServer 做本地缓存和 Redis 两级缓存
4. 方案四:保持现状,并让 guava 中的 cache 可配置
方案一:在 DataServer 中做本地缓存,然后 ManagerServer 中修改后异步通知 DataServer 进行变更。
a. 优点:保持了 DataServer 的独立性,可以实现较高性能的本地缓存,缓存变更可以异步通知,减少对 ManagerServer 的依赖。
b. 缺点:需要管理缓存一致性,确保通知机制可靠性。
方案二:在 ManagerServer 中做本地缓存。
a. 优点:可以更好地控制数据变更和缓存的一致性,减少了 DataServer 的负担。
b. 缺点:DataServer 的独立性较差,可能影响性能扩展。
方案三:ManagerServer 缓存给 Redis ,DataServer 做本地缓存和 Redis 两级缓存。
a. 优点:结合了两级缓存,兼顾了性能和数据一致性,同时减轻了 DataServer 的负担。
b. 缺点:增加了系统的复杂性和维护成本。
4.方案四:保持现状,并让 Guava 中的缓存可配置。
a. 优点:保持了现有的架构,较少的改动。
b. 缺点:如果需求变化,可能无法满足更高的性能和扩展需求。
综合考虑,我建议您可以考虑方案一或方案三,具体选择取决于您对数据一致性、性能扩展和系统复杂性的权衡。在实施选定方案时,确保进行充分的测试和监控,以确保系统运行稳定。另外,考虑使用缓存框架如 Redis 可以简化缓存的管理和一致性维护。
个人看好方案二啊!或者,是不是服务拆分有误,DataServer 和 ManagerServer 就不该拆开。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.