fixed issue preview
parent
f4af06bdff
commit
476dd1c5d9
|
@ -18,17 +18,17 @@ The single responsibility principle advocates for small and autonomous service
|
|||
|
||||
Workers in the application layer also help enable [asynchronism](https://github.com/donnemartin/system-design-primer#asynchronism) .
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#microservices) Microservices
|
||||
### Microservices
|
||||
|
||||
Related to this discussion are [microservices](https://en.wikipedia.org/wiki/Microservices) , which can be described as a suite of independently deployable, small, modular services. Each service runs a unique process and communicates through a well-definied, lightweight mechanism to serve a business goal. [1](https://smartbear.com/learn/api-design/what-are-microservices)
|
||||
|
||||
Pinterest, for example, could have the following microservices: user profile, follower, feed, search, photo upload, etc.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#service-discovery) Service Discovery
|
||||
### Service Discovery
|
||||
|
||||
Systems such as [Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) can help services find each other by keeping track of registered names, addresses, ports, etc.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#disadvantages-application-layer) Disadvantage(s) : application layer
|
||||
### Disadvantage(s) : application layer
|
||||
|
||||
* Adding an application layer with loosely coupled services requires a different approach from an architectural, operations, and process viewpoint (vs a monolithic system) .
|
||||
* Microservices can add complexity in terms of deployments and operations.
|
||||
|
|
|
@ -10,7 +10,7 @@ _[Source: Intro to architecting systems for scale](http://lethain.com/introducti
|
|||
|
||||
Asynchronous workflows help reduce request times for expensive operations that would otherwise be performed in-line. They can also help by doing time-consuming work in advance, such as periodic aggregation of data.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#message-queues) Message queues
|
||||
### Message queues
|
||||
|
||||
Message queues receive, hold, and deliver messages. If an operation is too slow to perform inline, you can use a message queue with the following workflow:
|
||||
|
||||
|
@ -25,26 +25,23 @@ RabbitMQ is popular but requires you to adapt to the 'AMQP' protocol and manage
|
|||
|
||||
Amazon SQS, is hosted but can have high latency and has the possibility of messages being delivered twice.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#task-queues) Task queues
|
||||
### Task queues
|
||||
|
||||
Tasks queues receive tasks and their related data, runs them, then delivers their results. They can support scheduling and can be used to run computationally-intensive jobs in the background.
|
||||
|
||||
Celery has support for scheduling and primarily has python support.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#back-pressure) Back pressure
|
||||
### Back pressure
|
||||
|
||||
If queues start to grow significantly, the queue size can become larger than memory, resulting in cache misses, disk reads, and even slower performance. [Back pressure](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) can help by limiting the queue size, thereby maintaining a high throughput rate and good response times for jobs already in the queue. Once the queue fills up, clients get a server busy or HTTP 503 status code to try again later. Clients can retry the request at a later time, perhaps with [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff) .
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#disadvantages-asynchronism) Disadvantage(s) : asynchronism
|
||||
### Disadvantage(s) : asynchronism
|
||||
|
||||
* Use cases such as inexpensive calculations and realtime workflows might be better suited for synchronous operations, as introducing queues can add delays and complexity.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#sources-and-further-reading-11) Source(s) and further reading
|
||||
### Source(s) and further reading
|
||||
|
||||
* [It's all a numbers game](https://www.youtube.com/watch?v=1KRYH75wgy4)
|
||||
* [Applying back pressure when overloaded](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html)
|
||||
* [Little's law](https://en.wikipedia.org/wiki/Little%27s_law)
|
||||
* [What is the difference between a message queue and a task queue?](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue-Why-would-a-task-queue-require-a-message-broker-like-RabbitMQ-Redis-Celery-or-IronMQ-to-function)
|
||||
|
||||
[](https://github.com/donnemartin/system-design-primer#communication)
|
||||
---------------------------------------------------------------------
|
|
@ -7,7 +7,7 @@ isdraft = False
|
|||
|
||||
There are two main patterns to support high availability:fail-over and replication.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#active-passive) Active-passive (Fail-Over)
|
||||
### Active-passive (Fail-Over)
|
||||
|
||||
With active-passive fail-over, heartbeats are sent between the active and the passive server on standby. If the heartbeat is interrupted, the passive server takes over the active's IP address and resumes service.
|
||||
|
||||
|
@ -15,7 +15,7 @@ The length of downtime is determined by whether the passive server is already ru
|
|||
|
||||
Active-passive failover can also be referred to as master-slave failover.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#active-active) Active-active (Fail-Over)
|
||||
### Active-active (Fail-Over)
|
||||
|
||||
In active-active, both servers are managing traffic, spreading the load between them.
|
||||
|
||||
|
@ -23,39 +23,39 @@ If the servers are public-facing, the DNS would need to know about the public IP
|
|||
|
||||
Active-active failover can also be referred to as master-master failover.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#disadvantages-failover) Disadvantage(s) : failover
|
||||
### Disadvantage(s) : failover
|
||||
|
||||
* Fail-over adds more hardware and additional complexity.
|
||||
* There is a potential for loss of data if the active system fails before any newly written data can be replicated to the passive.
|
||||
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#master-slave-and-master-master) Master-slave replication
|
||||
### Master-slave replication
|
||||
|
||||
The master serves reads and writes, replicating writes to one or more slaves, which serve only reads. Slaves can also replicate to additional slaves in a tree-like fashion. If the master goes offline, the system can continue to operate in read-only mode until a slave is promoted to a master or a new master is provisioned.
|
||||
|
||||
[![](https://camo.githubusercontent.com/6a097809b9690236258747d969b1d3e0d93bb8ca/687474703a2f2f692e696d6775722e636f6d2f4339696f47746e2e706e67) ](https://camo.githubusercontent.com/6a097809b9690236258747d969b1d3e0d93bb8ca/687474703a2f2f692e696d6775722e636f6d2f4339696f47746e2e706e67)
|
||||
_[Source: Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/) _
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#disadvantages-master-slave-replication) Disadvantage(s) : master-slave replication
|
||||
### Disadvantage(s) : master-slave replication
|
||||
|
||||
* Additional logic is needed to promote a slave to a master.
|
||||
* See [Disadvantage(s) : replication](https://github.com/donnemartin/system-design-primer#disadvantages-replication) for points related to both master-slave and master-master.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#master-master-replication) Master-master replication
|
||||
### Master-master replication
|
||||
|
||||
Both masters serve reads and writes and coordinate with each other on writes. If either master goes down, the system can continue to operate with both reads and writes.
|
||||
|
||||
[![](https://camo.githubusercontent.com/5862604b102ee97d85f86f89edda44bde85a5b7f/687474703a2f2f692e696d6775722e636f6d2f6b7241484c47672e706e67) ](https://camo.githubusercontent.com/5862604b102ee97d85f86f89edda44bde85a5b7f/687474703a2f2f692e696d6775722e636f6d2f6b7241484c47672e706e67)
|
||||
_[Source: Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/) _
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#disadvantages-master-master-replication) Disadvantage(s) : master-master replication
|
||||
### Disadvantage(s) : master-master replication
|
||||
|
||||
* You'll need a load balancer or you'll need to make changes to your application logic to determine where to write.
|
||||
* Most master-master systems are either loosely consistent (violating ACID) or have increased write latency due to synchronization.
|
||||
* Conflict resolution comes more into play as more write nodes are added and as latency increases.
|
||||
* See [Disadvantage(s) : replication](https://github.com/donnemartin/system-design-primer#disadvantages-replication) for points related to both master-slave and master-master.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#disadvantages-replication) Disadvantage(s) : replication
|
||||
### Disadvantage(s) : replication
|
||||
|
||||
* There is a potential for loss of data if the master fails before any newly written data can be replicated to other nodes.
|
||||
* Writes are replayed to the read replicas. If there are a lot of writes, the read replicas can get bogged down with replaying writes and can't do as many reads.
|
||||
|
@ -63,7 +63,7 @@ _[Source: Scalability, availability, stability, patterns](http://www.slideshare.
|
|||
* On some systems, writing to the master can spawn multiple threads to write in parallel, whereas read replicas only support writing sequentially with a single thread.
|
||||
* Replication adds more hardware and additional complexity.
|
||||
|
||||
### [](https://github.com/donnemartin/system-design-primer#sources-and-further-reading-replication) Source(s) and further reading: replication
|
||||
### Source(s) and further reading: replication
|
||||
|
||||
* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
|
||||
* [Multi-master replication](https://en.wikipedia.org/wiki/Multi-master_replication)
|
Loading…
Reference in New Issue