Java Web series summary posted: Java Web knowledge summary summary
Distributed ID
Common design of distributed ID:
- 1, or a sequence database from growing fields (disadvantages: possible single point of failure or performance problems)
- 2, UUID (Disadvantages: can not guarantee the increase, transmission capacity, large storage space, low query efficiency)
- 3, UUID-> INT64, add a timestamp to ensure the orderly
- 4, Redis generation, atomic operations INCR and can be implemented INCRBY Redis
- . 5, the snowflake algorithm Twitter
snowflake is distributed Twitter ID open generation algorithm, the result is a long type's ID. Its core idea is: Use as milliseconds ID 41bit, 10bit as the machine (5 bit data center, five-bit machine ID), 12bit (meaning that each node may be generated every millisecond as a serial number in ms 4096 ID), and finally there is a sign bit is always 0. - . 6, generates ZooKeeper
ZooKeeper main number sequence is generated by its znode data version can generate 32-bit and 64-bit data version number, the client can use a version number as the unique serial number.
Rarely use zookeeper to generate a unique ID. Mainly due to the need to rely ZooKeeper, and the API is a multi-step, competitive if larger, it is necessary to consider the use of a distributed lock. Therefore, the performance at high concurrent distributed environment, but also less than ideal.
More:
Distributed Systems unique ID generation scheme Summary
Idempotence
basic concept
Is the result of a request for a user or multiple requests of the same operation initiated is the same, multiple clicks will not produce side effects. Such as multiple clicks can not be repeated charge and so on.
solution
- 1, each request must have a unique identifier.
- 2, after processing the request, a record must have processed the request identifier may be stored in the database.
- 3, each request is processed until desired determination. As described above stored in the database record id, a unique key constraints, then re-insertion processing, it will be given.
- 4, the above operation is only an example, requires a combination of their own business processes, such as order payment scenario, the Redis Order stored, used as a unique key order_id, pay only the successful insertion of water, you can actually charge; status check, the actual processing before, check the status of orders, not dealt with before processing, processed directly back to the state.
More:
in-depth understanding of idempotency
Distributed Cache
- 1, page cache, browser cache
- 2, network cache (Web proxy caching, CDN)
- 3, server-side cache (cache databases such as MySQL, application-level cache, such as Redis)
- 4, multi-level cache architecture: Nginx local caching hot data cache solve the problem; Redis distributed cache back to the source to reduce the access rate; Tomcat cache against the impact of a cache miss / collapse after; improve query efficiency into the database
More:
"Distributed cache depth: from principle to practice" learning Notes (1)
"distributed cache depth: from principle to practice" study notes (2)
Distributed Lock
The three ways:
- 1, zoopkeeper - temporary node characteristics
- 2, redis - setnx characteristics
- 3, database implementation - the only constraint, an exclusive lock for update
Details:
Several use of distributed lock (redis, zookeeper, database)
Distributed Session
Cookie与Session
Cookie
What is
When a user accesses a server via HTTP protocol, the server will be a number of key / value key-value pairs (Cookie) returned to the client browser, and to these data with some restrictions, when conditions are met, this user time to visit this server, data integrity has been brought back to the server.
why
In order to record the user to access the Web over a period of time behavior path. Since the HTTP protocol is stateless protocol, the server can not know the next time to visit or not the user's last visit, so you can not do caching for a particular user's data to improve performance. This effect being Cookie, every request sent by the client are the same with the first information terminal to access the service provided (typically in HTTP Header information), so the server can be accessed according to the Cookie value divided the user.
good or not
advantage:
- Simple to use, easy to solve the problem of distributed
Disadvantages:
- 1, the storage limit, in the browser, restricted memory size and number (the number is restricted Cookie 50 total size does not exceed 4KB)
- 2, Cookie management confusion, each application has its own Cookie
- 3, security, storage in a browser can easily be stolen or tampered with
Session
What is
Introduced in front of Cookie allows server program to track each client's visit, but each client access must return these Cookie, if Cookie lot, which invisibly increase the amount of data transferred client and server, and the Session It appears precisely in order to solve this problem.
Each time the same client and server interaction time, do not need to always return all the Cookie value, but as long as a return ID, which is the first visit to the client server when generated, and each the client is unique. So that each client will have a unique ID, as long as the client returns this ID on the line, this ID is usually NANE of a Cookie JSESIONID.
good or not
Advantages: safe, repeatedly submit forms, etc. to verify the legitimacy of the scene may be generated by a token
disadvantages: not easily be shared among multiple servers.
to sum up
Cookie and Session is to maintain a continuous state of user access, the reason to keep it that way, on the one hand is to facilitate the business to achieve, on the other hand is designed to simplify service procedures, improve access performance, but it also brought another Some challenges, such as security issues, the application of a series of questions distributed deployment synchronization synchronization problems caused by cross-domain Session and Session, and these problems can be solved by a distributed framework Session.
Distributed Session how do
Distributed Session solve the problem
Since these questions have Cookie, Session also has its benefits, why not use it in conjunction with Session and Cookie? Here is distributed Session framework can solve the problem:
the unified management ◎ Session configurations.
◎ Cookie use of monitoring and standardized management.
◎ diversified Session store.
◎ Session dynamically modify the configuration.
◎ Session encryption key is periodically modified.
◎ adequate disaster recovery mechanisms to maintain the stability of the framework of use.
◎ Session various storage monitoring and alarm support.
Scalability ◎ Session frame compatible with more session mechanism as wapSession.
How ◎ Session and Cookie cross-domain sharing the same site and now there may be multiple domain names, how to share Session and Cookie is a challenging problem between different domains.
How to build Distributed Session
- 1, using ZooKeeper and other high-availability storage components to the consistency of coordination Cookie, unified management Cookie, subscribe to push public Cookie.
- 2, a distributed cache system, such as Memcache or the like to store the session Tair, the distributed architecture of FIG. Session:
