Using Java to achieve high concurrency without locking database operation steps sharing _java

1. How to have no locks in concurrency.
A very simple idea to convert concurrency into a single thread. The disruptor of Java is a good example. If you use Java Concurrentcollection class to do, the principle is to start a thread, run a queue, concurrency, the task into the queue, the thread rotation read this queue, and then executed sequentially.
In this design pattern, any concurrency becomes a single-threaded operation and is very fast. Now the node.js, or the more common ARPG service end is this design, "cycle" architecture.
In this way, our original system has 2 environments: Concurrent environment + "big circulation" environment
Concurrent environment is our traditional locking environment, low performance.
"Big circulation" environment is we use disruptor to open up the single thread without the lock environment, the performance is formidable.

2. How to improve the processing performance in the "circulation" environment.
Once a single thread is turned on, one of the threads will inevitably slow down as soon as the performance problem arises. So any operation in a single thread must not involve IO processing. What about the database operation?
Increase the cache. This idea is very simple, read directly from the memory, will inevitably be fast. As for the write, update operation, using a similar mentality, the operation submitted to a queue, and then run a separate thread to get the library. This ensures that IO operations are not involved in the "cycle".

The problem arises again:
If our game has only a large cycle is easy to solve, because the inside provides a perfect synchronization without locks.
But the actual game environment is concurrent and "the circulation" coexist, namely above 2 kinds of environment. So no matter how we design, we will inevitably find that there is a lock on the cache block.

3. Concurrent and "The circulation" how to coexist, eliminates the lock?
We know that if you want to avoid lock operation in the "cycle", then use "asynchronous" to give the operation to the thread. Combined with these 2 features, I slightly changed the database schema.
The original cache layer, there must be a lock, for example:

Copy Code code as follows:

Public Tablecache
{
Private hashmap<string, object> caches = new concurrenthashmap<string, object> ();
}

This structure is necessary to ensure the accurate operation of the cache in concurrent environments. But the "cycle" does not directly manipulate the cache for modification, so you must start a thread to update the cache, for example:

Copy Code code as follows:

private static final Executorservice EXECUTOR = Executors.newsinglethreadexecutor ();
Executor.execute (New Latencyprocessor (logs));

Class Latencyprocessor implements Runnable
{
public void Run ()
{
This can be arbitrary to modify the memory data. The asynchronous method is used.
}
}

OK, it looks beautiful. But another problem has arisen. In the process of high-speed access, it is very likely that the cache has not been updated, it was again acquired by other requests, the old data.

4. How do I guarantee the only correct caching of data in a concurrency environment?
We know that if there are only read operations and no writes, then this behavior is not required to be locked.
I use this technique, at the top of the cache, add a layer of caching, become a "first-level cache", the original is a "level two cache." Kind of like a CPU, right?
First-level caching can only be modified by the "cycle", but can be acquired concurrently, "the cycle", so there is no need to lock.
When database changes occur, in 2 cases:
1, the database changes in the concurrency environment, we are allowed to have a lock exists, so direct operation of level two cache, no problem.
2) "cycle" environment in the database changes, first of all, we put the change data stored in a first-level cache, and then to the asynchronous correction level two cache, fixed after the deletion of cache.
this way, no matter what the environment read the data, first of all to determine a cache, no longer judge level two cache.
This architecture guarantees absolute accuracy of the memory data.
and importantly: we have an efficient unlocked space to implement any of our business logic.

Finally, there are a few tricks to improve performance.
1. Now that our database operations have been processed asynchronously, there may be a lot of data that needs to be plugged in at a certain time, and we can delete some invalid operations by sorting the table, primary key, and operation type. For example:
a) Multiple updates for the same table with one primary key, the last time.
B) The same table with a primary key, all previous operations are invalid as long as the delete appears.
2. Now that we want to sort the operations, there is bound to be a sort of time, how to guarantee no lock? Use
Private final static Atomiclong _seq = new Atomiclong (0);
It is guaranteed that there is no lock and the globally unique self increase, as a time series.