Compare commits
10 Commits
8ed04ca177
...
135166d451
| Author | SHA1 | Date |
|---|---|---|
Huy Le
|
135166d451 | |
|
huylenq
|
73a1d7d33f | |
dgolant
|
a07e261677 | |
Iheb Haboubi
|
2d8231663f | |
Anand
|
e161b2a516 | |
Chetan Nair
|
7e8f93e57d | |
Kian-Meng Ang
|
7a094cec63 | |
mleers
|
79364dbbdc | |
Nnachevvv
|
578e29cff8 | |
Lawrence Chou
|
e8a867ee28 |
|
|
@ -61,7 +61,7 @@ See [Translations](TRANSLATIONS.md).
|
|||
|
||||
### Adding translations to new languages
|
||||
|
||||
Translations to new languages are always welcome! Keep in mind a transation must be maintained.
|
||||
Translations to new languages are always welcome! Keep in mind a translation must be maintained.
|
||||
|
||||
* Do you have time to be a maintainer for a new language? Please see the list of [translations](TRANSLATIONS.md) and tell us so we know we can count on you in the future.
|
||||
* Check the [translations](TRANSLATIONS.md), issues, and pull requests to see if a translation is in progress or stalled. If it's in progress, offer to help. If it's stalled, consider becoming the maintainer if you can commit to it.
|
||||
|
|
|
|||
|
|
@ -966,7 +966,7 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、
|
|||
* [キーバリューデータベース](https://en.wikipedia.org/wiki/Key-value_database)
|
||||
* [キーバリューストアの欠点](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
|
||||
* [Redisアーキテクチャ](http://qnimate.com/overview-of-redis-architecture/)
|
||||
* [メムキャッシュアーキテクチャ](https://www.adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
* [メムキャッシュアーキテクチャ](https://adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
|
||||
#### ドキュメントストア
|
||||
|
||||
|
|
@ -1712,7 +1712,7 @@ Notes
|
|||
* [Facebook Engineering](https://www.facebook.com/Engineering)
|
||||
* [Flickr Code](http://code.flickr.net/)
|
||||
* [Foursquare Engineering Blog](http://engineering.foursquare.com/)
|
||||
* [GitHub Engineering Blog](http://githubengineering.com/)
|
||||
* [GitHub Engineering Blog](https://github.blog/category/engineering)
|
||||
* [Google Research Blog](http://googleresearch.blogspot.com/)
|
||||
* [Groupon Engineering Blog](https://engineering.groupon.com/)
|
||||
* [Heroku Engineering Blog](https://engineering.heroku.com/)
|
||||
|
|
|
|||
35
README-vi.md
35
README-vi.md
|
|
@ -717,7 +717,7 @@ Có hai mẫu hình bổ sung lẫn nhau hỗ trợ khả năng khả dụng cao
|
|||
### Fail-over
|
||||
|
||||
#### Active-passive
|
||||
#### Chủ động - bị động
|
||||
#### Chủ động-bị động
|
||||
|
||||
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.
|
||||
Với fail-over chủ động - bị động, nhịp tim (heartbeat) sẽ được gửi giữa máy chủ chủ động và máy chủ bị động trực chờ. Nếu nhịp tim bị ngắt quãng, máy chủ bị động sẽ tiếp quản địa chỉ IP của máy chủ động và tiếp tục dịch vụ.
|
||||
|
|
@ -728,33 +728,46 @@ 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.
|
||||
Failover chủ động - bị động còn được biết dưới tên failover master-slave.
|
||||
|
||||
#### Active-active
|
||||
#### Chủ động-chủ động
|
||||
|
||||
In active-active, both servers are managing traffic, spreading the load between them.
|
||||
Trong mô hình chủ động-chủ động, cả hai server đều quản lý traffic, giàn trải load cho nhau.
|
||||
|
||||
If the servers are public-facing, the DNS would need to know about the public IPs of both servers. If the servers are internal-facing, application logic would need to know about both servers.
|
||||
Nếu các server là public-facing, DNS sẽ cần phải biết public IP của cả hai. Nếu các server là internal-facing, thì application logic cần biết về cả hai server.
|
||||
|
||||
Active-active failover can also be referred to as master-master failover.
|
||||
Failover trong chủ động-chủ động còn được biết đến là master-master failover.
|
||||
|
||||
### Disadvantage(s): failover
|
||||
### Bất lợi của failover
|
||||
|
||||
* Fail-over adds more hardware and additional complexity.
|
||||
* Fail-over đòi hỏi thêm phần cứng và tăng độ phức tạp.
|
||||
* There is a potential for loss of data if the active system fails before any newly written data can be replicated to the passive.
|
||||
* Sẽ có khả năng mất dữ liệu nếu hệ thống đang trạng thái chủ động fail trước khi dữ liệu mới được tái tạo vào hệ thống đang ở trạng thái bị động.
|
||||
|
||||
### Replication
|
||||
### Tái tạo
|
||||
|
||||
#### Master-slave and master-master
|
||||
#### Master-slave và master-master
|
||||
|
||||
This topic is further discussed in the [Database](#database) section:
|
||||
Chủ đề này được sẽ được phân tích thêm trong phần [Cơ sở dữ liệu](#database):
|
||||
|
||||
* [Master-slave replication](#master-slave-replication)
|
||||
* [Master-master replication](#master-master-replication)
|
||||
* [Tái tạo trong master-slave](#master-slave-replication)
|
||||
* [Tái tạo trong master-master](#master-master-replication)
|
||||
|
||||
### Availability in numbers
|
||||
### Các con số trong tính khả dụng
|
||||
|
||||
Availability is often quantified by uptime (or downtime) as a percentage of time the service is available. Availability is generally measured in number of 9s--a service with 99.99% availability is described as having four 9s.
|
||||
Tính khả dụng thường được lượng hoá bởi uptime (hoặc downtime) bằng tỉ lệ phần trăm của thời gian dịch vụ ở trạng thái khả dụng. Tính khả dụng nhìn chung được đo lường với đơn vị số "9"--như một dịch vụ khả dụng với mức 99.99% sử dụng bốn số "9".
|
||||
|
||||
#### 99.9% availability - three 9s
|
||||
#### 99.9% khả dụng - "ba 9"
|
||||
|
||||
| Duration | Acceptable downtime|
|
||||
|---------------------|--------------------|
|
||||
|
|
@ -763,7 +776,15 @@ Availability is often quantified by uptime (or downtime) as a percentage of time
|
|||
| Downtime per week | 10m 4.8s |
|
||||
| Downtime per day | 1m 26.4s |
|
||||
|
||||
| Thời lượng | Downtime chấp nhận |
|
||||
|---------------------|-----------------------|
|
||||
| Downtime hằng năm | 8 giờ 45 phút 57 giây |
|
||||
| Downtime hằng tháng | 43 phút 49,7 giây |
|
||||
| Downtime hằng tuần | 10 phút 4,8 giây |
|
||||
| Downtime hằng ngày | 1 phút 26,4 giây |
|
||||
|
||||
#### 99.99% availability - four 9s
|
||||
#### 99.99% khả dụng - "bốn 9"
|
||||
|
||||
| Duration | Acceptable downtime|
|
||||
|---------------------|--------------------|
|
||||
|
|
@ -772,6 +793,13 @@ Availability is often quantified by uptime (or downtime) as a percentage of time
|
|||
| Downtime per week | 1m 5s |
|
||||
| Downtime per day | 8.6s |
|
||||
|
||||
| Thời lượng | Downtime chấp nhận |
|
||||
|---------------------|--------------------|
|
||||
| Downtime hằng năm | 52 phút 35,7 giây |
|
||||
| Downtime hằng tháng | 4 phút 23 giây |
|
||||
| Downtime hằng tuần | 1 phút 5 giây |
|
||||
| Downtime hằng ngày | 8,6 giây |
|
||||
|
||||
#### Availability in parallel vs in sequence
|
||||
#### Tính khả dụng trong thực thi song song so với trình tự
|
||||
|
||||
|
|
@ -2256,6 +2284,7 @@ My contact info can be found on my [GitHub page](https://github.com/donnemartin)
|
|||
- Availability: tính sẵn có / hiện có / khả dụng
|
||||
- Traffic:
|
||||
- (Data) store: "CSDL" is not technically precise.
|
||||
- Failover
|
||||
|
||||
### Words that does have a translation but the English version is widely accepted among the Vietnamese-speakers
|
||||
|
||||
|
|
|
|||
|
|
@ -977,7 +977,7 @@ NoSQL 是**键-值数据库**、**文档型数据库**、**列型数据库**或*
|
|||
- [键-值数据库](https://en.wikipedia.org/wiki/Key-value_database)
|
||||
- [键-值存储的劣势](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
|
||||
- [Redis 架构](http://qnimate.com/overview-of-redis-architecture/)
|
||||
- [Memcached 架构](https://www.adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
- [Memcached 架构](https://adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
|
||||
#### 文档类型存储
|
||||
|
||||
|
|
@ -1723,7 +1723,7 @@ Notes
|
|||
* [Facebook Engineering](https://www.facebook.com/Engineering)
|
||||
* [Flickr Code](http://code.flickr.net/)
|
||||
* [Foursquare Engineering Blog](http://engineering.foursquare.com/)
|
||||
* [GitHub Engineering Blog](http://githubengineering.com/)
|
||||
* [GitHub Engineering Blog](https://github.blog/category/engineering)
|
||||
* [Google Research Blog](http://googleresearch.blogspot.com/)
|
||||
* [Groupon Engineering Blog](https://engineering.groupon.com/)
|
||||
* [Heroku Engineering Blog](https://engineering.heroku.com/)
|
||||
|
|
|
|||
|
|
@ -967,7 +967,7 @@ NoSQL 指的是 **鍵-值對的資料庫**、**文件類型資料庫**、**列
|
|||
* [鍵值對資料庫](https://en.wikipedia.org/wiki/Key-value_database)
|
||||
* [鍵值對資料庫的缺點](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
|
||||
* [Redis 架構](http://qnimate.com/overview-of-redis-architecture/)
|
||||
* [Memcached 架構](https://www.adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
* [Memcached 架構](https://adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
|
||||
#### 文件類型資料庫
|
||||
|
||||
|
|
@ -1713,7 +1713,7 @@ Notes
|
|||
* [Facebook Engineering](https://www.facebook.com/Engineering)
|
||||
* [Flickr Code](http://code.flickr.net/)
|
||||
* [Foursquare Engineering Blog](http://engineering.foursquare.com/)
|
||||
* [GitHub Engineering Blog](http://githubengineering.com/)
|
||||
* [GitHub Engineering Blog](https://github.blog/category/engineering)
|
||||
* [Google Research Blog](http://googleresearch.blogspot.com/)
|
||||
* [Groupon Engineering Blog](https://engineering.groupon.com/)
|
||||
* [Heroku Engineering Blog](https://engineering.heroku.com/)
|
||||
|
|
|
|||
24
README.md
24
README.md
|
|
@ -389,13 +389,13 @@ First, you'll need a basic understanding of common principles, learning about wh
|
|||
|
||||
### Step 2: Review the scalability article
|
||||
|
||||
[Scalability](http://www.lecloud.net/tagged/scalability/chrono)
|
||||
[Scalability](https://web.archive.org/web/20221030091841/http://www.lecloud.net/tagged/scalability/chrono)
|
||||
|
||||
* Topics covered:
|
||||
* [Clones](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
|
||||
* [Databases](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
|
||||
* [Caches](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
|
||||
* [Asynchronism](http://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism)
|
||||
* [Clones](https://web.archive.org/web/20220530193911/https://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
|
||||
* [Databases](https://web.archive.org/web/20220602114024/https://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
|
||||
* [Caches](https://web.archive.org/web/20230126233752/https://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
|
||||
* [Asynchronism](https://web.archive.org/web/20220926171507/https://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism)
|
||||
|
||||
### Next steps
|
||||
|
||||
|
|
@ -433,7 +433,7 @@ Generally, you should aim for **maximal throughput** with **acceptable latency**
|
|||
|
||||
### Source(s) and further reading
|
||||
|
||||
* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput)
|
||||
* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/fv/posts/understanding-latency-vs-throughput)
|
||||
|
||||
## Availability vs consistency
|
||||
|
||||
|
|
@ -461,7 +461,7 @@ Waiting for a response from the partitioned node might result in a timeout error
|
|||
|
||||
Responses return the most readily available version of the data available on any node, which might not be the latest. Writes might take some time to propagate when the partition is resolved.
|
||||
|
||||
AP is a good choice if the business needs allow for [eventual consistency](#eventual-consistency) or when the system needs to continue working despite external errors.
|
||||
AP is a good choice if the business needs to allow for [eventual consistency](#eventual-consistency) or when the system needs to continue working despite external errors.
|
||||
|
||||
### Source(s) and further reading
|
||||
|
||||
|
|
@ -597,7 +597,7 @@ DNS is hierarchical, with a few authoritative servers at the top level. Your ro
|
|||
|
||||
Services such as [CloudFlare](https://www.cloudflare.com/dns/) and [Route 53](https://aws.amazon.com/route53/) provide managed DNS services. Some DNS services can route traffic through various methods:
|
||||
|
||||
* [Weighted round robin](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)
|
||||
* [Weighted round robin](https://www.jscape.com/blog/load-balancing-algorithms)
|
||||
* Prevent traffic from going to servers under maintenance
|
||||
* Balance between varying cluster sizes
|
||||
* A/B testing
|
||||
|
|
@ -1015,7 +1015,7 @@ A key-value store is the basis for more complex systems such as a document store
|
|||
* [Key-value database](https://en.wikipedia.org/wiki/Key-value_database)
|
||||
* [Disadvantages of key-value stores](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
|
||||
* [Redis architecture](http://qnimate.com/overview-of-redis-architecture/)
|
||||
* [Memcached architecture](https://www.adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
* [Memcached architecture](https://adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
|
||||
#### Document store
|
||||
|
||||
|
|
@ -1668,12 +1668,12 @@ Handy metrics based on numbers above:
|
|||
| Design a content delivery network like CloudFlare | [figshare.com](https://figshare.com/articles/Globally_distributed_content_delivery/6605972) |
|
||||
| Design a trending topic system like Twitter's | [michael-noll.com](http://www.michael-noll.com/blog/2013/01/18/implementing-real-time-trending-topics-in-storm/)<br/>[snikolov .wordpress.com](http://snikolov.wordpress.com/2012/11/14/early-detection-of-twitter-trends/) |
|
||||
| Design a random ID generation system | [blog.twitter.com](https://blog.twitter.com/2010/announcing-snowflake)<br/>[github.com](https://github.com/twitter/snowflake/) |
|
||||
| Return the top k requests during a time interval | [cs.ucsb.edu](https://www.cs.ucsb.edu/sites/cs.ucsb.edu/files/docs/reports/2005-23.pdf)<br/>[wpi.edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) |
|
||||
| Return the top k requests during a time interval | [cs.ucsb.edu](https://www.cs.ucsb.edu/sites/default/files/documents/2005-23.pdf)<br/>[wpi.edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) |
|
||||
| Design a system that serves data from multiple data centers | [highscalability.com](http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html) |
|
||||
| Design an online multiplayer card game | [indieflashblog.com](https://web.archive.org/web/20180929181117/http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer-game.html)<br/>[buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) |
|
||||
| Design a garbage collection system | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/)<br/>[washington.edu](http://courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf) |
|
||||
| Design an API rate limiter | [https://stripe.com/blog/](https://stripe.com/blog/rate-limiters) |
|
||||
| Design a Stock Exchange (like NASDAQ or Binance) | [Jane Street](https://youtu.be/b1e4t2k2KJY)<br/>[Golang Implementation](https://around25.com/blog/building-a-trading-engine-for-a-crypto-exchange/)<br/>[Go Implemenation](http://bhomnick.net/building-a-simple-limit-order-in-go/) |
|
||||
| Design a Stock Exchange (like NASDAQ or Binance) | [Jane Street](https://youtu.be/b1e4t2k2KJY)<br/>[Golang Implementation](https://around25.com/blog/building-a-trading-engine-for-a-crypto-exchange/)<br/>[Go Implementation](http://bhomnick.net/building-a-simple-limit-order-in-go/) |
|
||||
| Add a system design question | [Contribute](#contributing) |
|
||||
|
||||
### Real world architectures
|
||||
|
|
@ -1764,7 +1764,7 @@ Handy metrics based on numbers above:
|
|||
* [Facebook Engineering](https://www.facebook.com/Engineering)
|
||||
* [Flickr Code](http://code.flickr.net/)
|
||||
* [Foursquare Engineering Blog](http://engineering.foursquare.com/)
|
||||
* [GitHub Engineering Blog](http://githubengineering.com/)
|
||||
* [GitHub Engineering Blog](https://github.blog/category/engineering)
|
||||
* [Google Research Blog](http://googleresearch.blogspot.com/)
|
||||
* [Groupon Engineering Blog](https://engineering.groupon.com/)
|
||||
* [Heroku Engineering Blog](https://engineering.heroku.com/)
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ generate () {
|
|||
cat $name.md | generate_from_stdin $name.epub $language
|
||||
}
|
||||
|
||||
# Check if depencies exist
|
||||
# Check if dependencies exist
|
||||
check_dependencies () {
|
||||
for dependency in "${dependencies[@]}"
|
||||
do
|
||||
|
|
|
|||
Loading…
Reference in New Issue