Nhất Quán Cuối Cùng

Vũ Huy Tâm

Đây là bản dịch của bài Eventually Consistent của Werner Vogels. Tác giả bài viết là CIO của Amazon và là cựu giáo sư khoa Khoa học Máy tính của trường Đại học Cornell (Mỹ). Bài báo đã đề xuất một hướng đi mới trong việc xây dựng các hệ thống dữ liệu lớn, tách khỏi cách tiếp cận của các hệ QT CSDL quan hệ truyền thống. Cách tiếp cận mới này giúp tăng khả năng sẵn sàng (availability) và mở rộng (scalability) lên rất nhiều, vốn là các ưu tiên hàng đầu của các hệ thống lớn trên Internet. Bài báo có tầm ảnh hưởng rất lớn và có thể nói, nó đã tạo “cơ sở lý luận” vững chắc cho phong trào NoSQL (Not Only SQL) đang phát triển rất mạnh. Đại biểu của phong trào này là các hệ thống mới phát triển gần đây như Dynamo (phát triển/áp dụng tại Amazon), Cassandra (Facebook, Digg), CouchDB, MongoDB… (Không biết các website lớn ở Việt nam có dùng mấy món này không?). Trong bài này tác giả đưa ra khái niệm eventual consistency – trong đó hệ thống cam kết rằng, một cập nhật xảy ra tại một điểm sẽ được lan truyền và sau một khoảng thời gian (không phải ngay tức khắc) sẽ đi đến mọi điểm trong hệ thống, tức là cuối cùng (eventually) hệ thống sẽ trở lại trạng thái nhất quán.  Thuật ngữ này tôi tạm dịch là “nhất quán cuối cùng”, thấy cũng hơi… chuối ;) nhưng không tìm được từ nào khác nên  đành tạm dùng. Nếu bạn biết từ nào hay hơn thì gợi ý cho tôi.
 

Nhất quán cuối cùng – Xây dựng hệ thống phân tán tin cậy ở phạm vi toàn cầu đòi hỏi sự thỏa hiệp giữa tính nhất quán và tính sẵn sàng

Nền tảng của điện toán đám mây của Amazon là các dịch vụ hạ tầng như S3 (Simple Storage Service), SimpleDB, và EC2 (Elastic Compute Cloud), cung cấp tài nguyên cho việc xây dựng các hệ thống tính toán ở phạm vi toàn cầu và rất nhiều các loại ứng dụng khác nhau. Yêu cầu đặt cho các dịch vụ hạ tầng đó là rất chặt; chúng cần đạt những tiêu chuẩn cao về các mặt bảo mật, khả năng mở rộng, hiệu năng, và hiệu quả về chi phí, trong khi phục vụ liên tục hàng triệu khách hàng từ khắp nới trên trái đất.

Bên dưới vỏ của các dịch vụ này là các hệ thống phân tán khổng lồ hoạt động trên phạm vi toàn cầu. Mức độ rộng lớn này tạo ra các thử thách mới, vì khi một hệ thống xử lý hàng nghìn tỷ yêu cầu, những sự kiện vốn có xác suất cực nhỏ giờ đây chắc chắn sẽ xảy ra, và chúng cần được tính đến ngay từ trong thiết kế và kiến trúc của hệ thống. Với qui mô toàn cầu của các hệ thống này, chúng ta thường dùng nhân bản (replication) để đảm bảo sự nhất quán và khả năng sẵn sàng. Mặc dù nhân bản giúp chúng ta tiến gần hơn tới đích, nó không thể đạt được một cách hoàn toàn trong suốt; trong một số điều kiện nhất định, khách hàng của các dịch vụ này sẽ phải đối diện với những hậu quả của các kỹ thuật nhân bản dùng bên trong các dịch vụ này.

Một trong các cách mà hiện tượng trên bộc lộ ra là trong loại nhất quán dữ liệu mà dịch vụ cung cấp, đặc biệt khi hệ thống phân tán ở dưới cung cấp một mô hình nhất quán cuối cùng trong việc nhân bản. Khi thiết kế những hệ thống lớn đó tại Amazon, chúng tôi áp dụng một số nguyên lý căn bản liên quan đến nhân bản ở qui mô lớn và chú trọng vào sự thỏa hiệp giữa tính sẵn sàng và độ nhất quán dữ liệu. Trong bài báo này tôi trình bày một vài cơ sở liên quan đã giúp định hướng cách tiếp cận của chúng tôi.
 

Bối cảnh lịch sử

Trong một thế giới hoàn hảo sẽ chỉ có một mô hình nhất quán dữ liệu: khi có một cập nhật xảy ra thì tất cả mọi người đọc đều nhìn thấy cập nhật đó. Lần đầu tiên điều này nổi lên như là một việc khó đạt được là trong các hệ thống CSDL vào cuối những năm 70. Bài viết hay nhất về chủ đề này là “Notes on Distributed Databases” của Bruce Lindsay và cộng sự. Nó đã vạch ra các nguyên lý cơ bản cho nhân bản và thảo luận một số kỹ thuật để giúp đạt được sự nhất quán. Nhiều kỹ thuật trong số đó cố gắng đạt được sự trong suốt về phân tán – tức là người dùng chỉ nhìn thấy một hệ thống duy nhất thay vì nhiều hệ thống cộng tác với nhau. Nhiều hệ thống trong thời kỳ này đi theo cách tiếp cận là thà đánh hỏng toàn bộ hệ thống chứ không phá vỡ tính trong suốt đó.

Vào giữa những năm 90, với sự ra đời của nhiều hệ thống Internet lớn hơn, các cách làm trên đã bị đem ra xét lại. Vào thời điểm đó mọi người bắt đầu xem xét ý tưởng rằng tính sẵn sàng có lẽ là tài sản lớn nhất của các hệ thống này, nhưng họ vẫn phải đánh vật với việc chọn ra yếu tố nào cần phải hy sinh. Eric Brewer, giáo sư về hệ thống tại Đại học California, Berkeley, tại thời điểm đó là người đứng đầu của Inktomi, đã tập hợp các phương án thỏa hiệp khác nhau trong một bài phát biểu tại hội nghị PODC (Principles of Distributed Computing) năm 2000. Ông đưa ra định lý CAP theo đó nói rằng trong ba yếu tố của một hệ thống chia xẻ dữ liệu – sự nhất quán, tính sẵn sàng, và mức độ chịu đựng đối với sự phân đoạn của mạng (tolerance to network partition) – thì tại mỗi thời điểm chỉ có thể đạt được hai yếu tố mà thôi. Một bài chứng minh đầy đủ hơn có thể tìm thấy trong một bài báo của Seth Gilbert và Nancy Lynch năm 2002.

Một hệ thống không chịu đựng phân đoạn mạng có thể đạt được tính nhất quán và tính sẵn sàng, và thường thực hiện bằng các giao thức nhân bản. Để đạt được điều này, hệ thống client và hệ thống lưu trữ phải ở trong cùng một môi trường; trong một số tình huống nhất định chúng sẽ suy xụp cùng nhau, và vì vậy client không nhận ra phân đoạn. Một nhận xét quan trọng là trong các hệ thống phân tán ở qui mô lớn thì việc mạng bị phân đoạn là một thực tế; do đó tính nhất quán và tính sẵn sàng không thể đạt được cùng nhau. Điều này có nghĩa là có hai lựa chọn trong việc bỏ đi yếu tố nào: nới lỏng mức độ nhất quán sẽ cho phép hệ thống vẫn sẵn sàng sử dụng trong điều kiện bị phân đoạn, trong khi đưa tính nhất quán lên làm ưu tiên hàng đầu nghĩa là trong một số điều kiện hệ thống sẽ không còn tính sẵn sàng.

Hai lựa chọn đòi hỏi developer phải ý thức được những gì mà hệ thống cung cấp. Nếu hệ thống nhấn mạnh vào yếu tố nhất quán, developer phải tính đến trường hợp hệ thống có thể không sẵn sàng, ví dụ, cho một thao tác ghi. Nếu thao tác ghi thất bại vì hệ thống không sẵn sàng, developer phải tính đến việc làm gì với dữ liệu đang cần ghi đó. Nếu hệ thống đề cao tính sẵn sàng, nó có thể luôn tiếp nhận thao tác ghi, nhưng trong một số tình huống nào đó một thao tác đọc không thể hiện kết quả mới được cập nhật đó. Khi đó developer lại phải quyết định liệu client có luôn đòi hỏi truy nhập vào dữ liệu cập nhật mới nhất hay không. Có một loạt các ứng dụng có thể chỉ cần dữ liệu hơi cũ một chút, vì thế rất thích hợp với mô hình này.

Về nguyên tắc, thuộc tính nhất quán của một hệ thống giao dịch theo như định nghĩa của ACID (Atomicity, Consistency, Isolation, Durability) thuộc về một loại đảm bảo nhất quán khác. Trong ACID, tính nhất quán liên quan đến việc đảm bảo rằng khi một giao dịch kết thúc thì CSDL ở một trạng thái nhất quán; ví dụ, khi chuyển tiền từ một tài khoản này sang một tài khoản khác thì tổng số tiền của cả hai tài khoản không được thay đổi. Trong các hệ thống dùng ACID, loại nhất quán này thường là trách nhiệm của developer viết giao dịch, nhưng cũng có thể được hỗ trợ bởi các ràng buộc toàn vẹn trong CSDL.
 

Tính Nhất quán – Client và Server

Có hai cách nhìn vấn đề nhất quán. Một cách là từ phía developer/client: họ quan sát cập nhật dữ liệu thế nào. Cách thứ hai là từ phía server: việc cập nhật đi qua hệ thống như thế nào cũng như hệ thống có thể đưa ra các đảm bảo nào về cập nhật đó.
 
Tính nhất quán nhìn từ phía client

Phía client gồm có các thành phần

  • hệ thống lưu trữ: Hãy tạm coi đây là một hộp đen, nhưng ta cần giả định rằng thực ra bên dưới đó là một hệ thống phân tán ở qui mô lớn và nó được xây dựng để đảm bảo độ bền bỉ và sẵn sàng cao.
  • Tiến trình A: Là tiến trình ghi vào và đọc ra từ hệ thống lưu trữ.
  • Tiến trình B và C: Hai tiến trình này độc lập với tiến trình A và cũng ghi và đọc từ hệ thống lưu trữ. Có thể đây là các tiến trình thực sự hay chỉ là các mạch (thread) trong cùng một tiến trình nhưng cũng không có gì khác biệt; điều quan trọng là chúng độc lập với nhau và cần giao tiếp để chia xẻ thông tin.

Nhất quán ở phía client liên quan đến việc các bên quan sát (trong trường hợp này là các tiến trình A, B, hoặc C) nhìn thấy các cập nhật trong hệ thống lưu trữ như thế nào và vào lúc nào. Dưới đây là các ví dụ minh họa các loại toàn vẹn khác nhau, trong đó tiến trình A vừa cập nhật một đối tượng dữ liệu:

  • Nhất quán mạnh (strong consistency): Sau khi cập nhật diễn ra, các lần đọc sau đó (của A, B, hoặc C) sẽ trả về giá trị vừa được cập nhật.
  • Nhất quán yếu (weak consistency): Hệ thống không đảm bảo các lần truy cập sau đó sẽ trả về giá trị cập nhật mới nhất. Để giá trị mới được trả về cần phải có một số điều kiện được thỏa mãn. Khoảng thời gian từ lúc cập nhật đến khi các tiến trình đọc có được đảm bảo sẽ đọc được giá trị mới được gọi là inconsistency window.
  • Nhất quán cuối cùng: Đây là một dạng đặc biệt của Nhất quán yếu; Hệ thống đảm bảo rằng nếu không có thêm cập nhật nào nữa, thì cuối cùng tất cả các truy nhập sẽ trả về giá trị cập nhật cuối cùng. Nếu không có trục trặc nào xảy ra, quãng thời gian lớn nhất của inconsistency window có thể được xác định dựa trên các yếu tố như độ trễ đường truyền, tải của hệ thống, và số bản sao dữ liệu được nhân bản. Hệ thống phổ biến nhất dùng mô hình này là DNS (Domain Name System). Các cập nhật đối với tên miền được phân tán dựa vào mẫu đã được cấu hình trước và kết hợp với việc cache; cuối cùng mọi khách hàng đều nhìn thấy cập nhật.

Mô hình toàn vẹn cuối cùng có một vài biến thể cần lưu ý:

  • causal consistency: Nếu tiến trình A đã thông báo cho tiến trình B rằng nó vừa cập nhật một mục dữ liệu, các truy nhập sau đó của B sẽ trả về giá trị vừa cập nhật, và một thao tác ghi mới sẽ ghi đè lên giá trị ghi lần trước. Các truy nhập của tiến trình C vốn không có quan hệ nhân quả với tiến trình A sẽ tuân theo qui luật eventual consistency.
  • read-your-writes consistency: Đây là một mô hình quan trọng, trong đó tiến trình A sau khi cập nhật dữ liệu sẽ luôn truy nhập được vào giá trị vừa được cập nhật và không bao giờ nhìn thấy giá trị cũ. Đây là một trường hợp đặc biệt của mô hình causal consistency.
  • session consistency: Đây là một phiên bản thực dụng của mô hình trên, trong đó một tiến trình truy nhập vào hệ thống lưu trữ trong ngữ cảnh của một phiên làm việc. Trong cùng một phiên làm việc đó, hệ thống đảm bảo read-your-writes consistency. Nếu phiên làm việc bị gián đoạn vì một tình huống trục trặc, một phiên làm việc mới được thiết lập và đảm bảo trên không còn giá trị cho phiên mới.
  • monotonic read consistency: Nếu một tiến trình đã nhìn thấy một giá trị nào đó của đối tượng, thì các truy nhập sau sẽ không bao giờ trả về giá trị cũ hơn thế.
  • monotonic write consistency: trong trường hợp này hệ thống đảm bảo các cập nhật của một tiến trình sẽ diễn ra tuần tự. Các hệ thống không đảm bảo được mức toàn vẹn này thường rất khó để lập trình.

Các thuộc tính trên có thể kết hợp với nhau. Ví dụ, một tiến trình có thể nhận được monotonic read consistency kết hợp với session consistency. Từ quan điểm thực tiễn, hai thuộc tính trên là đáng có nhất trong một hệ thống toàn vẹn cuối cùng, nhưng không phải lúc nào cũng đòi hỏi. Hai thuộc tính trên giúp developer lập trình dễ dàng hơn, trong khi cho phép hệ thống lưu trữ nới lỏng mức độ toàn vẹn và cung cấp độ sẵn sàng cao.

Như bạn đã thấy từ các biến thể này, một vài tình huống trở nên khả thi. Tùy thuộc vào các ứng dụng cụ thể có chấp nhận được các hậu quả hay không.

Nhất quán cuối cùng không phải là thuộc tính đặc thù của riêng các hệ thống phân tán cực lớn. Rất nhiều hệ QTCSDL đã xây dựng các kỹ thuật nhân bản theo cả hai chế độ đồng bộ và không đồng bộ. Với chế độ đồng bộ, bản sao được cập nhật trong cùng một giao dịch. Còn trong chế độ không đồng bộ, cập nhật được truyền đến bản sao với một độ trễ nhất định, thường thông qua log shipping. Ở chế độ này nếu CSDL chính bị hỏng trước khi log shipping diễn ra, các truy nhập vào bản sao sẽ cho ra giá trị cũ. Và để giúp tăng khả năng mở rộng cho các thao tác đọc, các hệ QTCSDL bắt đầu cho phép đọc từ bản sao, chính là một trường hợp kinh điển của việc đảm bảo nhất quán cuối cùng trong đó inconsistency window phụ thuộc vào khoảng thời gian giữa các lần log shipping.
 

Consistency từ phía server

Ở phía server ta cần nhìn sâu hơn vào việc cập nhật lan truyền trong hệ thống như thế nào để hiểu những yếu tố tạo ra các tình huống khác nhau mà developer có thể gặp phải. Trước khi bắt đầu ta hãy lập ra một vài định nghĩa:

N = số node chứa bản sao dữ liệu.

W = số bản sao cần xác nhận cập nhật trước khi cập nhật hoàn thành.

R = số bản sao được truy cập khi có một thao tác đọc xảy ra đối với một đối tượng dữ liệu.

Khi W+R>N, số bản sao được ghi và số bản sao được đọc luôn có phần chồng lên nhau và hệ thống có thể đảm bảo nhất quán mạnh. Trong hệ QTCSDL với nhân bản đồng bộ, N=2, W=2, và R=1. Client có thể đọc từ bản chính hoặc bản sao đều nhận được kết quả toàn vẹn. Với nhân bản không đồng bộ và việc đọc từ bản sao được cho phép, N=2, W=1, và R=1. Trong trường hợp này R+W=N, và tính toàn vẹn không còn được đảm bảo nữa.

Vấn đề của các cấu hình kể trên, vốn chính là dạng giao thức quorum cơ bản, là khi hệ thống không thể ghi vào W node vì lý do lỗi mạng, thao tác ghi buộc bị đánh hỏng, và làm cho hệ thống mất tính sẵn sàng. Với N=3 và W=3 và chỉ có hai node là hoạt động, hệ thống sẽ phải đánh hỏng thao tác ghi.

Trong các hệ thống lưu trữ phân tán cần cung cấp hiệu năng cao và độ sẵn sàng cao, số bản sao thường là lớn hơn 2. Các hệ thống chú trọng hoàn toàn vào khả năng chịu lỗi thường dùng N=3 (với cấu hình W=2 và R=2). Các hệ thống vốn phục vụ một lượng cực lớn các yêu cầu đọc thường nhân bản dữ liệu ra nhiều node hơn so với yêu cầu tối thiểu để chịu lỗi; N có thể hàng chục hoặc hàng trăm node; với R đặt bằng 1 để cho một thao tác đọc là đủ để trả về kết quả. Những hệ thống quan tâm đến toàn vẹn đặt W=N cho các cập nhật, có thể dẫn đến giảm xác suất thành công của các thao tác ghi. Với các hệ thống cần đặt khả năng chịu lỗi cao hơn tính toàn vẹn, một cấu hình thông dụng là đặt W=1 để giảm tối thiểu thời gian cập nhật và sau đó dựa vào một tiến trình lười để cập nhật các bản sao sau đó.

Cấu hình N, W, và R như thế nào phụ thuộc vào trường hợp thường gặp là gì và yếu tố hiệu năng nào cần được tối ưu hóa. Khi R=1 và N=W chúng ta tối ưu cho trường hợp thao tác đọc, và với W=1 và R=N chúng ta tối ưu để cho việc ghi là cực nhanh. Tất nhiên trong trường hợp sau, độ bền bỉ không được đảm bảo khi có sự cố, và nếu W<(N+1)/2 thì sẽ xuất hiện khả năng xung đột của các thao tác ghi khi các node được ghi không có phần gối lên nhau.

Nhất quán cuối cùng hoặc nhất quán yếu xảy ra khi W+R<=N, nghĩa là có khả năng các node cần đọc và các node cần ghi không gối lên nhau. Nếu cấu hình này là có chủ ý và không dựa trên trường hợp có sự cố, hợp lý nhất là đặt R=1. Điều này xảy ra trong hai trường hợp rất phổ biến: trường hợp thứ nhất là nhân bản ra thật nhiều node để giúp tăng khả năng mở rộng cho các thao tác đọc, như đã đề cập ở trên; trường hợp thứ hai là khi việc truy cập dữ liệu phức tạp hơn. Trong một mô hình key-value đơn giản, rất dễ so sánh các version để xác định giá trị mới nhất được ghi vào hệ thống, nhưng ở những hệ thống trả về một tập các đối tượng sẽ khó xác định hơn tập nào là đúng. Trong phần lớn các hệ thống đó khi tập các node cần ghi nhỏ hơn tập các bản sao, một kỹ thuật được áp dụng là cập nhật lười tới các node còn lại trong tập bản sao. Khoảng thời gian đến khi tất cả các bản sao được cập nhật là inconsistency window đã được nhắc đến ở trên. Khi W+R<=N, hệ thống sẽ bị tổn thương từ việc đọc các node chưa được cập nhật.

Nói chung các mô hình read-your-writes, session, và monotonic consistency có đạt được hay không phụ thuộc vào độ "dính" của các client vào server đang thực hiện các giao thức phân tán cho chúng. Nếu các lần thực hiện đều trên cùng một server, thì việc đảm bảo read-your-writes và monolithic read là tương đối dễ. Điều này làm cho việc quản lý cân bằng tải và chịu lỗi khó khăn hơn một chút, nhưng là một giải pháp đơn giản. Dùng phiên (session), vốn là một yếu tố kết dính, tạo một mức độ bộc lộ cho client để có thể luận đoán.

Đôi khi mô hình read-your-writes and monotonic có thể được thực hiện ở client. Bằng cách thêm version cho các thao tác ghi, client có thể bỏ các kết quả đọc với version cũ hơn so với version được đọc gần đây nhất.

Sự phân đoạn xảy ra khi một vài node trong hệ thống không nối tới được các node khác, nhưng cả hai nhóm đều vẫn có thể truy nhập được bởi các nhóm client. Nếu bạn dùng cách tiếp cận majority quorum cổ điển, thì đoạn có chứa W node bản sao sẽ tiếp tục được cập nhật trong khi đoạn kia mất tính sẵn sàng. Điều này cũng đúng với thao tác đọc. Nếu hai nhóm có phần gối nhau, theo định nghĩa nhóm thiểu số sẽ mất sẵn sàng. Phân đoạn không phải là hiện tượng thường xuyên, nhưng có xảy ra giữa các trung tâm dữ liệu (data center) cũng như bên trong mỗi trung tâm dữ liệu.

Đối với một số ứng dụng việc mất tính sẵn sàng của bất kỳ đoạn nào là không thể chấp nhận, và điều quan trọng là client đang kết nối vào đoạn đó vẫn tiếp tục thực hiện được các hành động của mình. Trong trường hợp đó, cả hai phía đều giành ra một tập các node lưu trữ để tiếp nhận dữ liệu, và thực hiện thao tác hợp nhất khi các đoạn được nối lại. Ví dụ, bên trong Amazon shopping cart sử dụng một hệ thống luôn-ghi (write-always) như vậy; trong trường hợp phân đoạn, khách hàng vẫn có thể thêm hàng vào giỏ hàng kể cả khi giỏ hàng ban đầu nằm ở đoạn khác. Ứng dụng giỏ hàng sẽ hỗ trợ hệ thống lưu trữ trong việc hợp nhất các giỏ hàng khi các phân đoạn được nối lại sau đó.
 
Amazon Dynamo

Một hệ thống sở hữu tất cả các thuộc tính trên với việc kiểm soát hoàn toàn nằm trong kiến trúc ứng dụng là Amazon Dynamo, một hệ thống lưu trữ key-value được sử dụng bên trong rất nhiều dịch vụ tạo nên nền tảng Amazon e-commerce và web services. Một mục đích thiết kế của Dynamo là cho phép chủ nhân của ứng dụng – người tạo instance của hệ thống lưu trữ Dynamo – vốn thường trải ra nhiều trung tâm dữ liệu – có thể tự chọn mức thỏa hiệp giữa tính nhất quán, độ bền bỉ, tính sẵn sàng, và hiệu năng để phù hợp với một mức chi phí nhất định.
 

Tóm tắt

Các hệ thống phân tán qui mô lớn cần phải có khả năng chịu đựng tính không nhất quán dữ liệu vì hai lý do: tăng hiệu năng đọc và ghi trong điều kiện tương tranh cao; và cần xử lý các trường hợp phân đoạn trong đó mô hình theo số đông (majority model) sẽ làm một phần của hệ thống mất sẵn sàng cho dù các node vẫn đang hoạt động.

Việc không nhất quán có thể chấp nhận được không là tùy thuộc vào ứng dụng. Trong mọi trường hợp developer cần nắm được các đảm bảo về nhất quán mà hệ thống lưu trữ cung cấp và cần tính đến các yếu tố này khi phát triển ứng dụng. Có một vài cải tiến thực tiễn của mô hình toàn vẹn cuối cùng, như session-level và monotonic read, vốn cung cấp những phương tiện tốt hơn cho developer. Rất nhiều trường hợp ứng dụng có thể xử lý được với đảm bảo toàn vẹn cuối cùng từ hệ thống lưu trữ mà không có vấn đề gì. Một trường hợp phổ biến cụ thể là một website trong đó chúng ta có khái niệm nhất quán theo cảm nhận của người dùng. Trong ngữ cảnh này, inconsistency window cần nhỏ hơn thời gian cần thiết để người dùng trở lại trang kế tiếp. Khoảng thời gian này cho phép cập nhật được lan truyền trong hệ thống trước khi có thao tác đọc tiếp theo.

Mục đích của bài viết này là để tăng nhận thức về độ phức tạp của việc xây dựng các hệ thống cần hoạt động trên phạm vi toàn cầu và đòi hỏi sự tinh chỉnh để đảm bảo chúng có thể cung cấp các dịch vụ với độ bền bỉ, sẵn sàng, và hiệu năng tốt mà các ứng dụng yêu cầu. Một trong các công cụ mà người thiết kế hệ thống có là độ dài của consistency window, trong đó các hệ thống này sẽ bộc lộ cho client thấy những thực tế của việc xây dựng những hệ thống qui mô lớn.




Tags: , ,

2 Comments
Posted on 20/7/2010 | Categories: Eventual Consistency

Các bài viết tương tự

Comments
  • Van (20/03/2012 12:26 am)

    Minh nghi nen dich ‘Eventually Consistent’ la ‘Đồng nhất toàn diện’

Leave a Reply

Hướng dẫn: Để nhập mã T-SQL bạn dùng thẻ <pre lang="tsql"> và </pre>.
Ví dụ: <pre lang="tsql">SELECT * FROM MyTable</pre>