https://blog.csdn.net/Be_Pretty_Better/article/details/82732908
1. Distributed session problem: Because in distributed systems, server clusters, the same service is usually on several different servers, when the browser for the first time sent the original request or session has failed, will be on the server side create a session, and sessionId in response header back to the browser saved in cookie. When the second visit to the browser, it will take sessionId Locate the session in the server, although access to the same URL twice, but the request is likely to hit on two different tomcat, so the second session before the request can not be found . This problem solution has the following five methods:
using the session shared database
used for redis session, k, v are sessionId, session, which has been integrated in springboot, add @EnableRedisHttpSession on redis configuration classes
used plus session token, token and session are temporary and unique, redis of k, v are the token, session
using tomcat comes session synchronization tool, but there is a delay effect is not good
to do ip hash operations at the gateway level, to ensure that requests for the same ip can play to the same tocmat
2. distributed cross-domain question: ajax request when the front page of the service interface system to access the current page is located, without any problems, but when the page to access the system, the request can be sent out successfully, can return successfully, but the browser will not allow display, this issue has four solution:
add "access-control-allow-origin " in response headers in
reverse proxy with nginx or zuul, request all hit reverse proxy server, the server sends a request through the reverse proxy, and returned to the ajax, browser appear to have the same system
with j sonp, the ajax-type setting jsonp, but jsonp can only get support request
ajax hit an interface of the system, this interface is encapsulated by httpclient retransmission request frame or other rpc
3. Distributed scheduling: the system will have a regular job, when the same service is deployed to multiple different servers at the same timing task will be be performed multiple times, such as timing redis backup, then the backup will be redis multiple copies, this is obviously wrong.
By using xxl-job unified dispatch center to ensure that the same task at the same time only one is executed.
4. stepwise things: a method A change his database, successful, and send the service request to another database B B modified by RPC, also successful, returns true, the result of the broken network, A B is not received In response, after a timeout, A database rollback, B does not move, so that consistency violation.
With lcn framework to address, lcn is people development, the core idea is "not to produce things, things that only a local porter", using 2pc protocol, that is, when two database operations are completed successfully, will give lcn signal, which at the same time lcn commit, otherwise lcn unified ROLLBACK
5. distributed idempotency: for example, re-form to submit questions, should submit multiple works only once, in conventional systems, multiple submissions will hit unified interface, then the interface internal request to heavy, but in a distributed system, multiple submissions may hit different servers, can no longer be in accordance with previous methods to re-
request with a request to do aop intercept in front notification, the judge over: solutions is there a token header, if released, without using uuid + timestamp manner, lock-based distributed globally unique token generated, is added to the request header, the token stored in the Redis, release. Surround notification request arrives, the request first determines the header
token can be found in Redis, if so, delete the token Redis, execution request interface. If no corresponding redis token, indicating that the request is a second or later call interception.
6. Distributed Lock: When multiple threads simultaneously read and write to a variable, will have a security thread, but the thread of traditional synchronized with other systems are not visible, so all need a thread are visible for all services locks.
III Solution: Based on the database, based on redission, zookeeper based. Zookeeper node built under a temporary appointment to the path nodes, only one thread at the same time be able to build a successful and can not create the same path before you delete, delete the definition of watch can monitor nodes, after deleting the other nodes can receive timely notification
and do not try to create a lock of polling. This is a difference in the way the basics of java, synchronized and lock in, lock there tryLock method, you can try to create a lock and get the return value, there is no lock can know the current locks, and processed, and can not be synchronized in lock when blocking live, until you can lock up. zookeeper
distributed lock similar lock, in the creation of a temporary node to create success and failure will have a return value.
redission manner: redission ReentantLock and two are the only two classes that implement the interface lock, reentantlock reentrant lock redission is distributed lock, and lock the same usage, based redis achieved.
Distributed Systems Frequently Asked Questions summary
https://blog.csdn.net/moranzi1/article/details/78572219