缓存服务器实现的架构问题
这是一个架构问题。 我的想法是拥有一台具有大内存的服务器，用作大对象缓存持有者。客户端将“操作”发送到该服务器（例如属性年龄<13的搜索人员）。然后，这台机器（让事情变得复杂的是，最好有更多该服务器的实例，并为每个实例分配人员列表以保存一半的数据，并且两个实例都可以处理查询 - MapReduce 样式）将返回符合条件的人。 其他“操作”将是特定的缓存刷新，或者说“将 id=3 的人员更新到实例...”等。
猜测最好的方法是 Oracle Coherence，但我想知道是否有人有其他开源解决方案，或想法。
一个简单的解决方案是将 EhCache 与 Hibernate 一起使用，但我不知道将使用什么协议将其转换为服务器（我看到发送操作作为调用“服务器”上的方法，并且这些方法返回以下人员的列表：匹配查询）。也许可以使用简单的 RMI。我还没有被说服，我想要一个更经过验证的解决方案，一个框架，如果有故障转移、自动发现和地图缩减，那就太好了。我想我可以将 GridGain 包装在我的 EhCache 解决方案之上并解决这个问题？这会不会太过分了（我可能只坚持使用这个数据网格服务器的一个实例）。
其他选择是兵马俑。问题是我对 Terracotta 不太了解，只知道你可以在实例之间共享数据。如果我将一个进程中的元素添加到分布式缓存中，并且在另一个进程中是否存在缓存的本地副本，并且仅复制差异？这对于每个进程都会查询本地缓存这一事实来说非常好，而且速度会非常快，但这也意味着客户端进程会使用大量内存。
那么有人有什么想法吗？
谢谢。
This is something of an architecture question.
I have this idea of having a server with huge memory, that is used as a big objects cache holder. The clients send "Actions" to this server(like Search Person with property age<13). And then, this machine(to complicate things it would be nice to have more instances of this server and distribute the Persons list for each instance to hold half the data, and both instances would work on the query - MapReduce style) will then return the Persons that match the criteria.
Other "Actions" would be a specific cache flush, or say "Update Person with id=3 to instance ...", etc.
Guess the best thing that does that it's Oracle Coherence, but I wonder if anybody has other open source solutions, or ideas.
One simple solution would be to use EhCache with Hibernate, but I do not know what protocol I would use to turn this into a server(I see sending the actions as invoking methods on the "server" and the methods return the list of Persons that match the query). Maybe simple RMI could be used. I'm not yet convinced, I would like a more proven solution, a framework, also it would be nice to have failover, autodiscovery and map reduce. I guess I could wrap GridGain on top of my EhCache solution and solve that? Would that be overkill(I may stick to only one instance of this datagrid server).
Other option would be Terracotta. The thing is I do not know very much about Terracotta, only that you can share data among instances. If I add elements from a process to the distributed cache, and in another process is there a local copy of the cache, and only differences are replicated? That would be great for the fact that every process would query the local cache and that would be very fast, but it will also mean much memory used in the client processes.
So anybody got any ideas?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
作为简单 EhCache 的简单解决方案，我想我可以使用 Hazelcast 来实现集群感知并调用“操作” - Hazelcast
MapReduce 作为解决方案再次被证明是有趣的。这非常有趣，因为他们说他们提供 MapReduce 并跟踪数据的位置，这应该非常快。我不确定如果我们没有超过两台服务器是否可以。
As the simple solution to a simple EhCache, I think I could use Hazelcast to implement cluster awarness and invoking the "Actions" - Hazelcast
Again the MapReduce could prove interesting as the solution. It's very interesting as they say they provide MapReduce and keeping track at the locality of data, that should be very fast. I'm not sure it is ok in case we do not have more than two servers.
为什么需要缓存？您在问题第一段中描述的内容听起来很像关系数据库，其表完全存储在内存中。您是否有任何可扩展性要求，可能需要将数据分布在集群中的多个服务器上？
Why do you need a cache? What you described in the first paragraph of your question sounds a lot like a relational database whose tables are stored entirely in memory. Do you have any scalability requirements that may require distributing your data across several servers in a cluster?
我相信 Terrastore 是为了解决这个问题而构建的，但是对 Terrastore 的访问应该是被禁止的进程中，而不是进程中（您没有具体说明您需要哪种访问权限）。
Terrastore是一个基于Terracotta的OSS项目。
I believe Terrastore is built to solve this problem, however access to Terrastore is intended to be out of process, not in process (you weren't specific what kind of access you need).
Terrastore is an OSS project based on Terracotta.
您也可以查看 Redis。它有非常好的查询语言。
You can check it out Redis as well. It has very good query language.