This article comes from the public number: Hook hook Java universe (wechat: Javagogo), mo to promote, all dry goods!
The original link: mp.weixin.qq.com/s/ReLPMdTKn… Author: Chen Bo
The introduction and architecture of cache
1. Cache component selection
-
Select a Cache component, such as local-cache, or open source Cache components such as Redis, Memcached, or Pika
-
If your business cache needs are special, you may want to consider whether to customize a new cache component directly or redevelop the open source cache to meet your business needs
Second, cache data structure design
Once you have identified the cache components, you need to design the cache data structure according to the characteristics of the business access.
For direct simple KV read and write services, you can package these business data into string, JSON, protocol buffer formats, serialized into byte sequences, and then directly write to the cache.
When reading, it first retrieves the byte sequence of the data from the cache component and then deserializes it.
For businesses that only need to access partial fields or need to perform calculations on the cache side, you can design data into Hash, Set, List, Geo structures and store them in caches that support complex collection data types, such as Redis and Pika.
Third, cache distribution design
Having identified the cache components and designed the cache data structure, the next step is to design the cache distribution. You can do it in three dimensions.
- To choose a distributed algorithm, do you use modulus or consistent Hash for distribution?
The model distribution scheme is simple, each key will only have certain cache nodes.
The consistent Hash distribution scheme is relatively complex, and the cache node corresponding to a key is uncertain. However, consistent Hash distribution can evenly distribute data access of failed nodes to other normal and viable nodes when some cache nodes are abnormal, so as to better ensure the stability of the cache system.
- How to implement distributed read and write access? Do cache clients Hash read and write data directly or do proxies distribute read and write routes?
The read/write performance is the best, but the Client must be aware of the distribution policy. When the cache deployment changes online, all cache clients need to be notified in time to avoid read/write exceptions. In addition, the Client implementation is complicated.
Through Proxy routing, the Client only needs to directly access the Proxy. The Proxy handles distribution logic and deployment changes, which is the most friendly for service application development. However, if the service access is added by one hop, the access performance may be compromised.
- Data migration
During the operation of the cache system, if the amount of data to be cached increases too fast, a large amount of cache data will be excluded, and the cache hit ratio and data access performance will decrease. In this case, data must be dynamically split from the cache node and partially migrated horizontally to other cache nodes.
The migration process needs to consider whether the migration is carried out by the Proxy or by the cache Server itself, or even not supported at all.
-
For Memcached, migration is generally not supported.
-
For Redis, the community version relies on the cache Server for migration.
-
For Codis, Admin, Proxy and back-end cache components are used to migrate.
Iv. Cache architecture deployment and operation and maintenance management
After designing the cache distribution strategy, the next step is to consider the architectural deployment and operation management of the cache.
Architecture deployment mainly considers how to pool, layer, and IDC the cache, and whether heterogeneous processing is required.
- Points pool
Different core data with high concurrent access needs to be separated into independent cache pools for separate access to avoid mutual influence. Non-core service data with low traffic volume can be mixed.
- layered
When accessing massive data or service data of more than 100,000 to 1,000,000 levels, layered access is recommended and access volume is allocated to avoid cache overload.
- Points to IDC
If the service system needs multi-IDC deployment or even remote multi-live deployment, the cache system needs to deploy multi-IDC.
To consider how to update cached data across IDC, you can use direct cross-IDC read and write; DataBus can also be used to synchronize messages from different IDCs with queue machines, and then the message processor can cache updates. It can also be cached by the DB Trigger of each IDC.
- Heterogeneous processing
In some extreme scenarios, multiple cache components need to be combined to achieve the best read/write performance.
- system
At the system level, in order to better manage the cache, we should also consider the servitization of the cache, and consider how the cache system can better manage the cluster, monitor the operation and maintenance.
Common considerations for caching design architecture
In the process of designing a cache architecture, there are some very important considerations, as shown in the figure below. Only when these considerations are clearly analyzed, can we design a better cache architecture.
Read/write mode
The first is the read/write mode of the value. Is it all read/write or only part read/write and change? Do you need internal calculations?
For example, the number of fans of users, many ordinary users have thousands to tens of thousands of fans, while big V’s fans are tens of millions or even hundreds of millions. Therefore, the list of fans can only be partially obtained rather than being read and written as a whole.
In addition, when determining whether a user follows another user, it is more efficient to directly check and judge the user from the following list and return True/False or 0/1 instead of pulling the user’s entire following list.
KV size
Next is the size of KV for different business data cache.
If the KV size of a single service is too large, it needs to be split into multiple KV for caching. However, if the KV sizes of different cached data are too different, they cannot be cached together to avoid low cache efficiency and mutual influence.
The number of key
The number of keys is also an important consideration.
If the number of keys is not large, you can store the full amount of data in the cache and use the cache as DB storage. If the cache reads miss, it indicates that the data does not exist and there is no need to go to the DB to query.
If the amount of data is large, only frequently accessed hot data is reserved in the cache. For cold data, access DB directly.
Reading and writing peak
If the peak read/write value of cached data is less than 100,000, it can be divided into an independent cache pool.
Once the peak read/write value of data exceeds 100,000 or even reaches the QPS level of 1 million, the cache needs to be processed by layers. You can use local-cache together with remote cache, or even the remote cache continues to be processed by layers and pools. In the microblogging business, most of the core business Memcached access is handled this way.
shooting
Cache hit ratio has a significant impact on the performance of the entire service architecture.
For services with high core concurrent access, reserve sufficient capacity to ensure high core service cache hit ratio.
For example, the Feed Vector Cache in Weibo has a perennial hit rate of 99.5% or more. In order to maintain the cache hit ratio continuously, the cache system needs to be continuously monitored for timely troubleshooting or failover. At the same time, if some cache nodes are abnormal or the hit ratio decreases, the failover solution needs to consider whether to adopt the access drift policy of consistent Hash distribution or the multi-layer data backup policy.
Expiry policies
You can set a short expiration time for the cold key to expire automatically.
You can also set a time stamp on a key and a long expiration time. For example, many service systems have keys like key_20190801.
Average cache penetration load time
Average cache penetration load times are also important in some business scenarios.
For some service data that takes a long time to load or requires complex calculation after cache penetration and has a large volume of traffic, configure more capacity to maintain a higher hit ratio and reduce the probability of penetrating DB to ensure the access performance of the entire system.
Cache operationability
For the operation and maintenance of the cache, we need to consider the cluster management of the cache system. How to expand and shrink the capacity with one key? How do cache components upgrade and change? How can I quickly find and locate problems? How to continuously monitor alarms?
It is better to have a complete o&M platform that integrates various O&M tools.
Cache security
Considering the security of cache, on the one hand, you can restrict the source IP address and only allow Intranet access. At the same time, you need to increase the access permission for some key commands to avoid serious consequences caused by attacks or misoperations.
With this in mind, you can make a point of caching your architecture.
Welcome big guys to pay attention to the public account of the Java universe (wechat: Javagogo), refuse hydrology, harvest dry goods!