21 | Code Duplication: Three tricks to get rid of code duplication
Why solve the code duplication problem?
When bugs appear in repeated codes, if there are too many repetitions or the code structure is not well understood, it is very likely that half of the bugs will be changed. Therefore, eliminating repeated codes can improve the maintainability of the code to a certain extent. Utilize the
factory Pattern + template method pattern, eliminate if...else and repeated code
Use abstract classes to implement unified methods and leave different methods for subclass implementation (template method pattern), and then select the corresponding bean to inject when using Use spring to complete the factory pattern, thereby reducing code duplication.
Use annotations + reflection to eliminate duplicate code
"Many common processing involving class structure can follow this pattern to reduce duplicate code"
It feels better to write a tool class. . .
Use the attribute copy tool to eliminate duplicate code
Use the Bean mapping tool,
for example, when there are a large number of attributes in DO and DTO that need to be assigned, this method can be used. I really wrote a dozen lines of attribute assignment between DTO and DO objects before. It's good to know.
BeanUtils.copyProperties(orderDTO, orderDO, "id");
22 | Interface Design: The language of dialogue between systems must be unified
The response of the interface should clearly indicate the processing result of the interface.
Two principles of interface design:
- Hiding the internal implementation from the outside
- When designing the interface structure, clarify the meaning of each field and the processing method of the client.
Clear interface design logic (example):
@Data
public class APIResponse<T> {
private boolean success;
private T data;
private int code;
private String message;
}
Clarify the version control strategy before developing the interface, and try to use a unified version control strategy to
clarify the synchronization and asynchrony of the interface
23 | Cache design: caching can be icing on the cake or it can be detrimental
Don't use Redis as a database
Reason:
- When the data in Redis disappears and causes business logic errors, the business cannot be restored if the original data is not preserved.
- Redis cache size cannot exceed memory size
Therefore, when using Redis as a cache, we need to pay attention to two points:
3. From the perspective of the client, the characteristics of the cached data must have the original data source, and loss is allowed.
4. From the perspective of the Redis server, the cache system can The amount of saved data must be smaller than the original data.
Pay attention to the cache avalanche problem
Broadly speaking, there are two reasons for the cache avalanche:
the first is that the cache system itself is unavailable, causing a large number of requests to be directly returned to the database;
the second is that a large number of keys at the application design level are in The same time expires, resulting in a large amount of data back to the source.
The first type belongs to the system configuration problem, here we only solve the second type.
Solution 1: Differentiate the cache expiration time
Solution 2: Keep the cache from actively expiring
Pay attention to the problem of cache breakdown
Solution 1: Double-check distributed locks, but this method is too strict and will reduce the concurrency efficiency of the system
Solution 2: Use in-process locks to limit, so that each node can send back with one Source database
Solution 3: Use tools to limit the number of concurrent members
Pay attention to the problem of cache penetration
Solution 1: For non-existing data, also set a special Value to the cache
Solution 2: Bloom filter
Pay attention to the cache data synchronization strategy.
Update the database first and then delete the cache. When accessing, load data to the cache as needed, and try to set an appropriate cache expiration time, so that even if there is an inconsistency, the data can be synchronized in time after the cache expires.
24 | After the business code is written, does it mean that it is ready for production?
steamed. . . can't read. . .
25 | Asynchronous processing is easy to use, but it is very easy to use it wrong
Asynchronous processing is often used with MQ middleware
- To account for the loss of messages or processing interruptions of the asynchronous process, a backup line is required to compensate.
- During asynchronous processing, the possibility of message duplication needs to be considered, and the processing logic needs to be idempotent to prevent repeated processing.
- In the case of multiple instances of different services listening to messages in a microservice scenario, generally different services need to receive the same message at the same time, while multiple instances of the same service only need to poll to receive messages. We need to confirm whether the message routing configuration of MQ meets the requirements to avoid the problem of repeated or missing messages.
- Pay attention to dead letter messages that cannot be processed all the time, which may cause the problem of blocking MQ.
26 | Data storage: How does NoSQL and RDBMS complement each other?
The selection of databases is mainly complementary, and no database is omnipotent.
Redis's reading performance for a single piece of data is much higher than that of MySQL, but it is not suitable for range searches.
InfluxDB's aggregation efficiency for time series data is much higher than that of MySQL, but it is not a general-purpose database because there is no primary key.
ES's full-text search capability for keywords is much higher than that of MySQL, but the update efficiency of fields is low, and it is not suitable for storing frequently updated data.
In the end, we proposed a mixed architecture solution of MySQL + Redis + InfluxDB + ES, which fully utilizes the strengths of various databases and cooperates with each other to form a storage architecture that can handle various complex queries and high concurrent read and write.
27 | Data Sourcing: Nothing on the client side can be trusted
- The calculation of the client is not trustworthy, for example: the shopping cart calculates the payable, it is only for reference
- All parameters from the client need to be verified to determine their legality, so as to prevent someone from submitting directly through the front end through interface tools and other methods, resulting in data exceptions
- Except for the information in the request body, any information in the request header cannot be trusted either. Data such as IP and cookie are for reference only and cannot be used in important business logic. Third-party logins and other methods can be used for unique identification
- If the interface faces external users, there must be no parameters such as user ID. The current user ID must come from the server, and only authenticated users will leave ID on the server.
28 | Security bottom line: When money is involved, anti-swiping, limited and anti-heavy must be considered
The use of open platform resources needs to consider anti-swiping , such as sending text messages or website traffic, etc. The solutions include normal use process identification, human-machine identification, single-person limit and global limit, etc. Virtual
assets cannot be used indefinitely . The total number of coupons must be set before the coupons to prevent large losses caused by
cash. The in and out of money must be linked to the order and to achieve idempotence.
Any fund operation needs to generate an order with business attributes on the platform side. It must be done before the order Fund operations.
We must do a good job of anti-heavy, that is, to achieve idempotent processing, and idempotent processing must be the whole link. The full link here means that the same business order number needs to run through from front to back, so as to realize the final payment prevention.
29 | Data and Code: Data is Data, Code is Code
For SQL injection , avoiding parameterized queries is the best way to plug the leak; for MyBatis, we need to use "#{}" for parameterization.
For XSS attacks , three things need to be ensured when dealing with security issues. (Original text below)
First, leak plugging should be carried out fundamentally and from the lowest level, and try not to do it at the high-level framework level, otherwise the leak plugging may not be thorough.
Second, plugging should consider both entry and exit. Not only must the data be escaped or filtered when it is stored in the database, but it must also be escaped again when the data is retrieved and displayed to ensure nothing goes wrong.
Third, in addition to directly plugging the loophole, we can also limit the power of the loophole through some additional means. For example, set the HttpOnly attribute for cookies to prevent data from being read by scripts; for example, limit the maximum storage length of fields as much as possible. Even if a vulnerability occurs, the hacker's ability to construct complex attack scripts will be limited due to length issues.
30 | How is sensitive data properly stored and transmitted?
User passwords cannot be stored in simple encryption (such as md5), let alone in plain text. It is necessary to use a globally unique, random salt (such as UUID) with a certain length, and to cooperate with the one-way hash algorithm to save names and ID cards
. Sensitive information that can be reversibly decrypted and queried needs to be stored using a symmetric encryption algorithm. The suggestion of the author of this book is to save the desensitized data and ciphertext in the business database, and use the encryption service independently for data encryption and decryption; the key and initialization vector needed for symmetric encryption can be stored separately from the business
database . Always transmit via SSL/TLS encryption