The product boss with a technical background shared an article in the WeChat group "The Core Points and Best Practices of Payment Platform Architecture Design Review" in the official account. At that time, I roughly scanned it on the way to work, and later, my boss passed it to me and let me take a good look.
I took a good look at it yesterday and today. It should be said that I studied hard and gained a lot.
-summarize
-The author turned out to be a big cow
- "Scalable Service Architecture: Frameworks and Middleware"
-Learn about the Fastpay project in the future
Article address: https://mp.weixin.qq.com/s/y8v9Hd4VD-Ymh8gToU27eQ Of course, the Internet has gone crazy.
-summarize
Finally figured out what optimistic locking is. Use the version number or timestamp of the data record in the update operation of the data to ensure strong data consistency.
We use this optimistic lock when the channel notifies us of the payment result or the payment result.
Guanlin also uses optimistic locking when changing the available balance of the account. If the update is unsuccessful, it will retry in an infinite loop until the update is successful.
The task initiated by the agency payment also uses the status value of the record to be sent to ensure that the agency payment is not repeatedly initiated.
pessimistic lock
sql lock table. I used this method in coding at the end of 2016, and now I have a deeper understanding of "pessimistic locking". " An Example of Database "Lock": Discussion on the Problem of Duplicate Primary Keys in Concurrent Scenarios
Set db connection timeout
At 0:19 a.m. on April 16th, due to many "Lock wait timeout exceeded;" exceptions in the payment table, resulting in "[DUBBO] Thread pool is EXHAUSTED!", the thread pool was full, and the failure continued until 3:00. Because the application thread pool is full, all transactions fail. The payment table and the payment on behalf of the table are two tables. If the db timeout is set, only the payment will be affected, at least the payment on behalf of the payment will not be affected. Bloody lesson!
Likewise, the read cache also needs to set a timeout. Otherwise, it will also cause avalanches.
cache usage
The author gave 16 best practices. So useful.
- Separate the services that use the cache, and use different cache instances for core services and non-core services;
- If it is a shared cache, pay attention to the naming of the key (set a unique prefix for each application) to avoid the cache being overwritten (data confusion);
- The cache is generally used to speed up the read operation of the database. Generally, the cache is accessed first, and then the database is accessed, so the setting of the cache timeout time is very important. An Internet company once encountered a situation in which the cache timeout was set to a long time due to an operation and maintenance error, which dragged down the thread pool of the service and eventually led to a service avalanche.
- Data that is accessed infrequently should not be placed in the cache
- The cached data is not easy to be too large, especially Redis, because Redis uses a single-threaded model , when the data of a single cache key is too large, it will block the processing of other requests.
- Under normal circumstances, the order of reading is the cache first, then the database; the order of writing is the database first, then the cache.
- When using the cache, there must be a downgrade process. (There is a problem with the cache or invalidation, read db)
New code should be compatible with old data
When refactoring code logic, remember! The new logic should be compatible with the transaction or logic currently running on the line
affairs
The operations in the transaction should be as few as possible to improve the transaction execution time (reduce the duration of the lock). I have this awareness, it resonates. In addition, the author mentioned that the principle of data consistency is guaranteed using eventual consistency.
-The author turned out to be a big cow
The book "Scalable Service Architecture: Framework and Middleware" was mentioned twice in the article. After reading it on JD.com, it turns out that the author of this article, Li Yanpeng, is the editor-in-chief. Instantly feel that its person NB.
Li Yanpeng, co-founder of the "Cloud Era Architecture" technology community.
Cloud era architecture: http://www.cloudate.net/
Another editor-in-chief of "Scalable Service Architecture: Framework and Middleware", Jia Boyan , has a special blog in Jianshu, and has read several technical articles, which is more difficult. https://www.jianshu.com/u/c98c50394601
- "Scalable Service Architecture: Frameworks and Middleware"
I read the introduction and evaluation on jd, it is a very good book. If you can read it, your technical ability will definitely improve a lot. But just looking at the table of contents, some chapters are difficult. This is a new book, which was published in March this year. It costs more than 80 yuan and is a little expensive. The leader asks if he can use the departmental funds to buy some books for the department. https://item.jd.com/12308233.html
-Learn about the Fastpay project in the future
Development kit: https://gitee.com/robertleepeak/fastpay
A unified payment system that integrates aggregated payment and fund clearing and settlement. What I do is a payment project, and the business and technology need to be improved. Therefore, it is necessary to understand this after a long drought.