建筑设计数据的一致性分布式分析系统 [英] Architectural design for data consistency on distributed analytic system
问题描述
我的重构分析系统，该系统会做大量的计算，我需要对可能的建筑设计一些想法，我面临的数据一致性问题。
I am refactoring an Analytic system that will do a lot of calculation, and I need some ideas on possible architectural designs to a data consistency issue I am facing.
当前建筑
我有一个队列为基础的系统，其中不同的请求应用程序创建最终由工人使用的消息。
I have a queue based system, in which different requesting applications create messages that are eventually consumed by workers.
每个的请求应用的分解一个大的计算成小块，这将通过工人被发送到队列和处理的
Each "Requesting App" breaks down a large calculation into smaller pieces that will be sent to the queue and processed by the workers.
当所有的作品完成后，原始的要求的应用程式的将巩固的结果。
When all the pieces are finished, the originating "Requesting app" will consolidate the results.
此外，工的消耗，以处理请求（重要从集中式数据库（SQL Server）的信息：工人不改变数据库的任何数据，只消耗它的）。
Also, the workers consume information from a centralized database (SQL Server) in order to process the requests (Important: the workers do not change any data on the database, only consume it).
问题
确定。到现在为止还挺好。当我们包括更新数据库的信息网络服务的问题出现了。这可以在任何时候发生，但它是非常关键的，每个大的计算源于同一请求应用看到的数据库上的数据相同。
Ok. So far, so good. The problem arises when we include a web service that updates the information on the database. This can happen at any time, but it is critical that each "large calculation" originated from the same "Requesting App" sees the same data on the database.
例如：
- 应用的 A 的生成消息A1和A2，它发送队列
- 工人的 W1 的拿起消息A1进行处理。
- Web服务器更新数据库，从国家的 S0 的变化来的 S1 的
- 工人的 W2 的拿起消息A2进行处理
- App A generates messages A1 and A2, sending it to queue
- Worker W1 picks up message A1 for processing.
- The web server updates the database, changing from state S0 to S1.
- Worker W2 picks up message A2 for processing
我刚刚不容使用的数据库的状态S1有工人W2。整个计算是一致的，应该使用previous S0状态。
I just can´t have worker W2 using state S1 of the database. for the whole calculation to be consistent it should use the previous S0 state.
的思考
-
A 锁定模式以prevent更改数据库中同时有从中工人消费信息的Web服务器。
A lock pattern to prevent the web server from changing the database while there is a worker consuming information from it.
- 劣势：锁定可能会在很长一段时间，因为计算形式不同的请求应用程序可能会重叠（A1，B1，A2，B2，C1，B3等）。
- cons: The lock might be on for a long time, since the calculation form different "Request Apps" might overlap (A1, B1, A2, B2, C1, B3, etc.).
创建新层，数据库和工人之间（即控制由REQ数据库缓存服务器。应用程序）
Create new layer between the database and the workers (a server that controls db caching by req. app)
- 劣势：添加另一层可能会强加显著的开销，而且是大量的工作，因为我将不得不重新改写工人的持久性（很多$ C $的（也许？） C）。
- cons: Adding another layer might impose significant overhead (maybe?), and it is a lot of work, since I will have to rewrite the persistence of the workers (a lot of code).
我未决第二个解决方案，但不是很自信。
I am pending to the second solution, but not very confident about it.
任何高见？我在设计它错了，还是失去了一些东西？
Any brilliant ideas ? Am I designing it wrong, or missing something ?
OBS：
- 这是一个巨大的2层遗留系统（在C＃），我们正在尝试
演变成与作为最小的努力作为一个更灵活的解决方案
可能的。 - 每个工人可能在不同的服务器上运行。
推荐答案
谢谢大家的帮助。
因为我相信这是问题可能在其他方案往常一样，我想和大家分享我们选择了解决方案。
Since I believe this is problem might be usual in other scenarios, I would like to share the solution we chose.
思考更彻底地了解这个问题，我理解它到底是什么。
Thinking more thoroughly about the problem, I understood it for what it really is.
- 我需要某种形式的会话控制的每个作业
- 有在过程中缓存充当了会话控制每个作业
现在的计算已经发展到分发，我只需要我的发展缓存分发为好。
Now the calculation has evolved to be distributed, I just needed to evolve my cache to be distributed as well.
在为了做到这一点，我们选择使用内存数据库（哈希值），部署为一个单独的服务器。 （在这种情况下 Redis的的）。
In order to do that, we chose to use an In-Memory Database (hash-value), deployed as a separate server. (in this case Redis).
现在每当我开始工作的时候，我创建作业的ID并将它传递给他们的信息
Now every time I start a job, I create a ID for the job and pass it to their messages
在每个工人希望从数据库中的一些信息，它会：
When each worker wants some information from the database, it would:
- 查找在Redis的数据（与作业ID）
- 如果数据是在Redis的，使用数据
- 如果不是这样，从SQL加载它，并将其保存在Redis的（与作业ID）。
在作业结束时，我清除与作业ID相关联的所有哈希值。
At the end of the job, I clear all hashes associated with the job ID.
这篇关于建筑设计数据的一致性分布式分析系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
