Front end separation
Reference 🔗
1. The front and back ends are not separated from the architecture mode
When the front and back ends are not separated, the page logic processing and page rendering are all completed by the back end. For example, the most representative MVC three-tier framework. The user initiates the request to the server control layer (Controller), which calls the Model processor (Model) and render the View (View) and finally returns the page to the client.
This architecture requires back-end r&d to focus on front-end HTML, CSS code, etc. The front end cannot be debugged independently, and the front and back ends cannot be developed in parallel, resulting in low development efficiency and high maintenance cost.
- Advantages: View and Model are reusable and can be used independently
- Cons: Controller code is too bloated
2. The front and back ends are not completely separated from the architecture mode
In this paper, RESTful architecture is taken as the starting point to discuss the architecture mode that the front and back end are not completely separated. At present, most of the front and back end architectures are not completely separated. The back end provides RESTful apis (in layman’s terms, Http APIS for transporting JSON data). The front-end invokes the back-end Http API through AJAX requests, and completes the binding of page data, and finally completes the rendering of the page by the client browser. This architecture seems to have achieved complete separation of the front and back ends. In fact, the back-end interface still needs to pay attention to the front-end UI display, which is heavily customized for the front-end interface. In a multi-terminal scenario, the backend needs to implement multiple sets of apis. This architecture is defined as the “Incomplete separation of the front and back end architecture pattern” because of the tight coupling of the front and back end data and business.
3. Separation of the front and back end architecture mode
The NodeJS layer is introduced as the service bridge layer, NodeJS layer is built by the front-end engineer. NodeJS server runs JS scripts on the server side, enabling front-end personnel to quickly start building their own servers. With the introduction of NodeJS, a large amount of front-end logic calculation and page rendering can be done in the Intranet environment of the server in advance to improve the front-end access performance. Figure 6 shows the data and page rendering flow with the complete separation of the front and back architectural patterns.
Redis implements distributed locking
1. The background
Redis is a single-process single-thread mode, using the queue mode to change the concurrent access into serial access, and there is no competition between multiple clients for Redis connection. Secondly, Redis provides some commands SETNX and GETSET, which can facilitate the realization of distributed locking mechanism.
2. Implement
The SETNX command (SET if not exists) syntax is as follows: SETNX key value Function: SET the key to value and return 1 if and only if the key does not exist. If the given key already exists, SETNX does nothing and returns 0.
GETSET key value Sets the value of the given key to value and returns the old value of the key, an error if the key exists but is not a string, and nil if the key does not exist.
GET key function: Returns the string value associated with the key, or nil if the key does not exist.
Syntax of the DEL command: DEL key [key… Run the following command to delete one or more keys:
Reference 🔗
nodejs
A javascript runtime environment that enables javascript to run independently of the browser. Node.js is such a server-side, non-blocking I/O, event-driven JavaScript runtime environment.
Pessimistic lock, optimistic lock
Pessimistic locking
- It refers to the conservative attitude towards data being modified by other transactions, including the current transactions of the system, as well as transactions from external systems, and therefore keeping the data locked throughout the data processing process. Pessimistic lock is divided into shared lock and exclusive lock
- Pessimistic locking applies to scenarios where write operations are frequent. If a large number of read operations occur, locks will be added to each read operation, which increases the overhead of locking and reduces the throughput of the system.
Optimistic locking
- Optimistic locking does not deliberately use the locking mechanism of the database itself, but ensures the correctness of data according to the data itself. MVCC is an implementation of optimistic locking.
- This method is suitable for scenarios where read operations are frequent. If a large number of write operations occur, data conflicts are more likely. To ensure data consistency, the application layer needs to constantly retrieve data, which increases a large number of query operations and reduces the throughput of the system.
- Optimistic locking is generally implemented in the following two ways:
- Using Version numbers is implemented using the Version logging mechanism, which is the most common implementation of optimistic locking. What is data version? This is to add a version identifier to the data, typically by adding a numeric version field to the database table. When the data is read, the value of the Version field is read together, incrementing the version value with each update of the data. When we submit the update, compare the current version information of the database table with the version value extracted for the first time. If the current version number of the database table is equal to the version value extracted for the first time, it will be updated; otherwise, it is considered as expired data.
- The second way to implement optimistic locking with timestamp is similar to the first way. The same way is to add a field to the table that requires optimistic locking. The name of the field does not matter, and the field type is timestamp, similar to the above version. Also check the timestamp of the data in the current database and compare it with the timestamp obtained before the update when the update is submitted. If the timestamp is consistent, it is OK; otherwise, it is version conflict.
Read lock, write lock/shared lock, exclusive lock
Shared lock (S lock) is also called read lock. If transaction T locks data object A with S lock, transaction T can read A but cannot modify A. Other transactions can only lock A with S lock but cannot lock X until T releases S lock on A. This guarantees that other transactions can read A, but cannot make any changes to A until T releases the S lock on A.
Exclusive lock (X lock) is also called write lock. If transaction T locks data object A with X, transaction T can either read A or modify A, and no other transaction can lock A again until T releases the lock on A. This ensures that no other transaction can read or modify A until T releases the lock on A.
For read operations, read locks can be added. Once a table is read locked, other requests can add read locks to the table again, but not write locks. (When a request reads data, other requests can also read but not write data, because if another thread writes data, the current thread will not read the latest data. This is called unrepeatable reading.)
For write operations, a write lock can be added to the table. Once a write lock is added to the table, other requests cannot add read and write locks to the table. While one request is writing data, the other requests cannot do anything because the other requests cannot see the changes until the current transaction commits. This can lead to dirty reads, unrepeatable reads, and phantom reads.)
Both read and write locks are blocking locks.
If T1 adds a write lock to the table, it is T2’s request to add a write lock to the table. At this time, T2 will not return directly, but will remain blocked until T1 releases the lock on the table. Then t2 may successfully lock the table and obtain the result.
Mutual exclusion problem in FTP preallocated thread pool server
Data inconsistency may exist in multithreaded programs, so how to ensure data consistency? Consider only one thread accessing data at a time. A mutex is a lock. Mutex variables use a specific data type: pthread_mutex_t. Mutex variables are initialized before being used, using the following function: pthread_mutex_t
#include <pthread.h>
int pthread_mutex_init(pthread_mutex_t *restrict mutex, const pthread_mutexattr_t *restrict attr);
int pthread_mutex_destroy(pthread_mutex_t *mutex);
Copy the codeSimply initialize the mutex with the default property, setting the last parameter to NULL.
The mutex lock function is as follows:
#include <pthread.h>
int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_trylock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t *mutex);
Copy the codeMVVM
The biggest difference between MVVM and MVC is that it realizes the automatic synchronization of View and Model. That is, when the property of Model changes, we no longer need to manually manipulate Dom elements to change the display of View. Instead, the display of the property corresponding to the View layer will be automatically changed after the property is changed.
JWT: Token authentication
Json Web Token (JWT) is currently the most popular cross-domain authentication solution.
The JWT solution is as follows: The authentication information is returned to the client, the JWT token is provided to the client, and stored in the client. Next time the client accesses other pages, the token is put in the header of all requests, and the authentication information needs to be sent back to the server.
The JWT is divided into three parts: header, payload, signature
The header and payload are two JSON objects that are converted into strings using the Base64URL algorithm. The signature is the signature of the first two parts (which can be interpreted as encryption) to prevent data tampering.
How to understand the three paradigms popularly
The first normal form: 1NF is the atomicity constraint on attributes, which requires attributes to have atomicity and cannot be decomposed again. Second normal form: 2NF is a unique constraint on records, requiring records to be uniquely identified, that is, the uniqueness of entities. Third normal Form: 3NF is a constraint on field redundancy, that is, no field can be derived from any other field, which requires that the field have no redundancy.
Advantages and disadvantages of formal design
Advantages:
- Data redundancy can be reduced as far as possible, making the update fast and small
Disadvantages:
- Multiple tables are required for query association, which reduces write efficiency and increases read efficiency and makes index optimization more difficult