설계 문제 : 응용 프로그램의 공유, 동기화, 데이터 액세스… 최상의 접근 방식?

Question

작업 항목이 제출되어 작업량에 따라 사용자에게 할당되는 웹 응용 프로그램 (ASP.NET)이 있습니다.

사용자의 워크로드는 현재 사용자에게 할당 된 항목 (및 기타 요소)을 기반으로 알고리즘을 사용하여 계산됩니다. 각 새 항목은 현재 작업량이 가장 낮은 상태에서 사용자에게 할당되어 작업량이 증가합니다. 항목을 완성하면 사용자의 워크로드가 줄어 듭니다. 품목은 제출, 할당 및 동시에 완료되므로 작업량 레벨이 지속적으로 변경됩니다. 작업 항목은 SQL 데이터베이스에 저장됩니다.

사용자 기반의 최신 워크로드 사진을 사용하여 모든 할당 결정을 내릴 수있는 방법이 필요합니다.

내 아이디어는 캐시에 워크로드 정보를 읽고 쓰기 동기화 된 스토어를 제공하는 것입니다.

이것이 최선의 접근 방식입니까? 아니면 데이터베이스를 사용하여 잠금을 제어해야합니까? 내 응용 프로그램에서 병 넥을 피하려면 어떻게해야합니까?

조언을 많이 감사합니다.

Answer 1

This depends on many factors, when you refer to the cache do you mean the standard cache provided by Asp.Net?

Is it absolutely critical that you always have the most up to date information, or if two requests are made to be allocated is it ok for them to get allocated to the two least busy users at the moment the request was made?

You can indeed use a cache to store this information, however this generally assumes you will only be using one server, is it likely that you will be using clustering or load balancing for high loads?

The best advice I can give you is to build a well designed application, with a rich domain model representing the loads of each user and the queue and loosely coupled data access and plenty of automated unit and system tests. This way you can build a working application, get the system up and running quickly without worrying to much about optimisation and start performance testing\profiling as soon as possible.

If\when you encounter performance issues, you can then identity the bottlenecks by profiling\tracing and add optimisation as appropriate, which might be caching or optimised queries\views or combinations of things.

If you try to second guess where you're bottlenecks are and remove them, you will likely guess wrong and damage the design of the system. A well designed system can be optimised when you need it.

The way I would initially envisage this, would be a relational database (possibly using views or stored procedures to grab workload summary information quickly) with a data mapping layer between this and the domain model (which can use caching, lazy loading and identity mapping to provide efficiencies if needed). The domain model would largely hold a representation of the workload.

I would expect this to have users, work items, work queue and allocation strategy classes. Much of this could be kept in memory or stored locally between requests, each request could be represented by an event which would update the model.

E.g.
User completes a work item
Site raises a domain event to notify the domain model of change
Domain model receives event and updates work load for user

Work allocation would then be a matter of asking the domain model to allocate the work (which it would do via a strategy of finding the least allocated user) when needed. This could happen in the background outside of individual work requests and events raised to notify users next time they ask for work.

Answer 2

Use the database to control this.

If for some reason, in the future, you need to expand out to utilize a web farm then you won't have a problem. However, if you are caching the data and working locally then it will cause interesting things to happen.

Also, you can take advantage of web garden settings to help manage any load your server would have; which isn't exactly possible in a cached situation.

Second, realize that this probably doesn't have to be perfect. If you have a high amount of work coming in (like distributing leads in a call center) then just getting really close as long as it's fast is all that matters.

Answer 3

I would use a database to control this, as it's highly unlikely users will be completing work quickly enough to need a more real-time approach.

So I would have a series of tables, relating to work items, which you can query to calculate current work levels, and thus determine the next person to receive a particular work item.

You could then have a series of stored procedures to mark work items as complete, or to allocate a work item to someone.

To minimize bottle-necks ensure your database is normalised well, and your stored procedures do not use many tables, and this should ramp up nicely.

To check this, you could write some test harnesses to ensure the allocation of work items, and performance is what you desire under high usage.