Hội nghị HighLoad++ tiếp theo sẽ được tổ chức vào ngày 6 và 7 tháng 2020 năm XNUMX tại St. Petersburg.
Thông tin chi tiết và vé . HighLoad++ Siberia 2019. Hội trường "Krasnoyarsk". Ngày 25 tháng 12, 00:XNUMX. Luận văn và .
Điều xảy ra là các yêu cầu thực tế xung đột với lý thuyết, trong đó các khía cạnh quan trọng đối với một sản phẩm thương mại không được tính đến. Buổi nói chuyện này trình bày một quy trình lựa chọn và kết hợp các phương pháp tiếp cận khác nhau để tạo ra các thành phần nhất quán Nhân quả dựa trên nghiên cứu học thuật dựa trên yêu cầu của một sản phẩm thương mại. Người nghe sẽ tìm hiểu về các phương pháp lý thuyết hiện có đối với đồng hồ logic, theo dõi sự phụ thuộc, bảo mật hệ thống, đồng bộ hóa đồng hồ và lý do MongoDB quyết định sử dụng một số giải pháp nhất định.
Mikhail Tyulenev (sau đây gọi tắt là MT): – Tôi sẽ nói về tính nhất quán của Nguyên nhân - đây là một tính năng chúng tôi đã làm việc trong MongoDB. Tôi làm việc trong một nhóm hệ thống phân tán, chúng tôi đã làm việc đó khoảng hai năm trước.
Trong quá trình đó, tôi đã phải làm quen với rất nhiều nghiên cứu học thuật, vì tính năng này đã được nghiên cứu khá kỹ. Hóa ra không có một bài viết nào phù hợp với những gì được yêu cầu trong cơ sở dữ liệu sản xuất do các yêu cầu rất cụ thể có thể có trong bất kỳ ứng dụng sản xuất nào.
Tôi sẽ nói về cách chúng tôi, với tư cách là người tiêu dùng Nghiên cứu học thuật, chuẩn bị thứ gì đó từ đó mà sau đó chúng tôi có thể giới thiệu cho người dùng của mình như một món ăn làm sẵn tiện lợi và an toàn khi sử dụng.
Tính nhất quán nhân quả. Hãy xác định các khái niệm
Để bắt đầu, tôi muốn nói một cách khái quát Tính nhất quán của Nhân quả là gì. Có hai nhân vật - Leonard và Penny (phim truyền hình "The Big Bang Theory"):
Giả sử Penny đang ở Châu Âu và Leonard muốn tổ chức cho cô ấy một bữa tiệc bất ngờ. Và anh ấy không thể nghĩ ra điều gì tốt hơn là ném cô ấy ra khỏi danh sách bạn bè của mình, gửi cho tất cả bạn bè của anh ấy một bản cập nhật trên nguồn cấp dữ liệu: “Hãy làm cho Penny hạnh phúc!” (cô ấy đang ở Châu Âu, trong khi cô ấy ngủ, cô ấy không nhìn thấy tất cả những thứ này và không thể nhìn thấy nó, bởi vì cô ấy không có ở đó). Cuối cùng, cô ấy xóa bài đăng này, xóa nó khỏi Nguồn cấp dữ liệu và khôi phục quyền truy cập để không nhận thấy bất cứ điều gì và không có scandal.
Tất cả điều này đều ổn, nhưng hãy giả sử rằng hệ thống được phân phối và mọi thứ có một chút sai sót. Ví dụ: có thể xảy ra trường hợp hạn chế quyền truy cập của Penny xảy ra sau khi bài đăng này xuất hiện, nếu các sự kiện không liên quan đến nhân quả. Trên thực tế, đây là một ví dụ về thời điểm cần có tính nhất quán Nhân quả để thực hiện chức năng kinh doanh (trong trường hợp này).
Trên thực tế, đây là những thuộc tính khá không tầm thường của cơ sở dữ liệu - rất ít người hỗ trợ chúng. Hãy chuyển sang các mô hình.
Mô hình nhất quán
Chính xác thì mô hình nhất quán trong cơ sở dữ liệu là gì? Đây là một số đảm bảo mà hệ thống phân tán đưa ra về dữ liệu nào khách hàng có thể nhận được và theo trình tự nào.
Về nguyên tắc, tất cả các mô hình nhất quán đều đề cập đến mức độ giống nhau của một hệ thống phân tán với một hệ thống chạy, chẳng hạn như trên một nút trên máy tính xách tay. Và đây là điểm tương tự giữa một hệ thống chạy trên hàng nghìn “Nút” được phân phối theo địa lý với một máy tính xách tay, trong đó về nguyên tắc tất cả các thuộc tính này được thực hiện tự động.
Vì vậy, các mô hình nhất quán chỉ được áp dụng cho các hệ thống phân tán. Tất cả các hệ thống trước đây đã tồn tại và vận hành ở cùng một tỷ lệ dọc đều không gặp phải những vấn đề như vậy. Có một Bộ đệm đệm và mọi thứ luôn được đọc từ nó.
Người mẫu mạnh mẽ
Trên thực tế, mô hình đầu tiên là Strong (hay đường khả năng thăng tiến, như người ta thường gọi). Đây là mô hình nhất quán đảm bảo rằng mọi thay đổi, sau khi được xác nhận rằng nó đã xảy ra, sẽ hiển thị cho tất cả người dùng hệ thống.
Điều này tạo ra một trật tự chung cho tất cả các sự kiện trong cơ sở dữ liệu. Đây là một đặc tính nhất quán rất mạnh và thường rất đắt. Tuy nhiên, nó được hỗ trợ rất tốt. Nó rất đắt và chậm - chỉ hiếm khi được sử dụng. Đây được gọi là khả năng tăng.
Có một thuộc tính khác mạnh hơn được hỗ trợ trong Spanner - được gọi là Tính nhất quán bên ngoài. Chúng ta sẽ nói về nó một lát sau.
Nguyên nhân
Điều tiếp theo là Nhân quả, đó chính xác là điều tôi đang nói đến. Có một số cấp độ phụ khác giữa Mạnh mẽ và Nhân quả mà tôi sẽ không nói đến, nhưng tất cả đều tóm gọn lại về Nhân quả. Đây là một mô hình quan trọng vì nó là mô hình mạnh nhất trong tất cả các mô hình, tính nhất quán mạnh nhất khi có mạng hoặc các phân vùng.
Nguyên nhân thực sự là một tình huống trong đó các sự kiện được kết nối bởi mối quan hệ nhân quả. Rất thường xuyên, họ được coi là Đọc quyền của bạn theo quan điểm của khách hàng. Nếu khách hàng đã quan sát một số giá trị, anh ta không thể thấy các giá trị trong quá khứ. Anh ấy đã bắt đầu nhìn thấy các bài đọc tiền tố. Tất cả đều dẫn đến cùng một điều.
Nhân quả như một mô hình nhất quán là một thứ tự một phần của các sự kiện trên máy chủ, trong đó các sự kiện từ tất cả các máy khách được quan sát theo cùng một trình tự. Trong trường hợp này là Leonard và Penny.
Cuối cùng
Mô hình thứ ba là Tính nhất quán cuối cùng. Đây là điều mà tất cả các hệ thống phân tán đều hỗ trợ, mô hình tối thiểu hoàn toàn có ý nghĩa. Nó có nghĩa như sau: khi chúng tôi có một số thay đổi trong dữ liệu, đến một lúc nào đó chúng sẽ trở nên nhất quán.
Lúc này cô ấy không nói gì, nếu không cô ấy sẽ chuyển sang trạng thái Kiên định bên ngoài - đó sẽ là một câu chuyện hoàn toàn khác. Tuy nhiên, đây là một mô hình rất phổ biến, phổ biến nhất. Theo mặc định, tất cả người dùng hệ thống phân tán đều sử dụng tính nhất quán cuối cùng.
Tôi muốn đưa ra một số ví dụ so sánh:
Những mũi tên này có ý nghĩa gì?
- Độ trễ. Khi cường độ nhất quán tăng lên, nó sẽ trở nên lớn hơn vì những lý do rõ ràng: bạn cần tạo nhiều bản ghi hơn, nhận được xác nhận từ tất cả các máy chủ và nút tham gia vào cụm rằng dữ liệu đã có ở đó. Theo đó, Tính nhất quán cuối cùng có câu trả lời nhanh nhất, bởi vì ở đó, theo quy định, bạn thậm chí có thể ghi nó vào bộ nhớ và về nguyên tắc, điều này là đủ.
- Khả dụng. Nếu chúng ta hiểu điều này là khả năng hệ thống phản hồi khi có sự cố mạng, phân vùng hoặc một loại lỗi nào đó, thì khả năng chịu lỗi sẽ tăng lên khi mô hình nhất quán giảm, vì đối với chúng ta, chỉ cần một máy chủ tồn tại và cùng một lúc là đủ. thời gian tạo ra một số dữ liệu. Tính nhất quán cuối cùng không đảm bảo bất cứ điều gì về dữ liệu - nó có thể là bất cứ điều gì.
- Sự bất thường. Tất nhiên, đồng thời, số lượng dị thường tăng lên. Trong Tính nhất quán mạnh mẽ, chúng hầu như không tồn tại, nhưng trong Tính nhất quán cuối cùng, chúng có thể là bất cứ thứ gì. Câu hỏi đặt ra: tại sao mọi người chọn Tính nhất quán cuối cùng nếu nó chứa đựng những điều bất thường? Câu trả lời là các mô hình Tính nhất quán cuối cùng có thể áp dụng được và các điểm bất thường tồn tại, chẳng hạn như trong một khoảng thời gian ngắn; có thể sử dụng trình hướng dẫn để đọc và đọc ít nhiều dữ liệu nhất quán; Thường có thể sử dụng các mô hình nhất quán mạnh mẽ. Trong thực tế, điều này có hiệu quả và thường số lượng dị thường bị hạn chế về mặt thời gian.
định lý CAP
Khi bạn nhìn thấy những từ nhất quán, sẵn có – bạn nghĩ đến điều gì? Đúng vậy - định lý CAP! Bây giờ tôi muốn xóa tan huyền thoại... Không phải tôi - mà là Martin Kleppmann, người đã viết một bài báo tuyệt vời, một cuốn sách tuyệt vời.
Định lý CAP là một nguyên tắc được xây dựng vào những năm 2000 rằng Tính nhất quán, Tính khả dụng, Phân vùng: lấy hai bất kỳ và bạn không thể chọn ba. Đó là một nguyên tắc nhất định. Nó đã được chứng minh là một định lý vài năm sau đó bởi Gilbert và Lynch. Sau đó, điều này bắt đầu được sử dụng như một câu thần chú - các hệ thống bắt đầu được chia thành CA, CP, AP, v.v.
Định lý này thực tế đã được chứng minh cho các trường hợp sau... Thứ nhất, Tính khả dụng không được coi là một giá trị liên tục từ 0 đến hàng trăm (100 - hệ thống “chết”, XNUMX - phản hồi nhanh; chúng ta đã quen coi nó như vậy) , nhưng như một thuộc tính của thuật toán, đảm bảo rằng với tất cả các lần thực thi, nó sẽ trả về dữ liệu.
Không có một từ nào về thời gian phản hồi cả! Có một thuật toán trả về dữ liệu sau 100 năm - một thuật toán hoàn toàn tuyệt vời hiện có, là một phần của định lý CAP.
Thứ hai: định lý đã được chứng minh cho những thay đổi về giá trị của cùng một khóa, mặc dù thực tế là những thay đổi này có thể thay đổi kích thước. Điều này có nghĩa là trong thực tế, chúng thực tế không được sử dụng, bởi vì các mô hình có tính nhất quán cuối cùng khác nhau, tính nhất quán mạnh mẽ (có thể).
Tất cả những thứ này để làm gì? Hơn nữa, định lý CAP ở dạng chính xác mà nó đã được chứng minh là thực tế không thể áp dụng được và hiếm khi được sử dụng. Ở dạng lý thuyết, nó bằng cách nào đó hạn chế mọi thứ. Hóa ra một nguyên tắc nào đó đúng về mặt trực giác, nhưng nhìn chung vẫn chưa được chứng minh.
Tính nhất quán nhân quả là mô hình mạnh nhất
Điều đang xảy ra bây giờ là bạn có thể nhận được cả ba điều: Tính nhất quán, Tính khả dụng khi sử dụng Phân vùng. Đặc biệt, tính nhất quán Nhân quả là mô hình nhất quán mạnh nhất, vẫn hoạt động khi có sự phân vùng (sự gián đoạn trong mạng). Đó là lý do tại sao nó lại được quan tâm nhiều đến vậy và đó là lý do tại sao chúng tôi đã sử dụng nó.
Thứ nhất, nó đơn giản hóa công việc của các nhà phát triển ứng dụng. Đặc biệt, sự hỗ trợ tuyệt vời từ máy chủ: khi tất cả các bản ghi xảy ra bên trong một máy khách được đảm bảo đến theo cùng một trình tự trên máy khách khác. Thứ hai, nó chịu được các phân vùng.
Bếp nội bộ MongoDB
Nhớ rằng đã là bữa trưa, chúng tôi đi vào bếp. Tôi sẽ cho bạn biết về mô hình hệ thống, cụ thể là MongoDB là gì dành cho những người lần đầu tiên nghe về cơ sở dữ liệu như vậy.
MongoDB (sau đây gọi là “MongoDB”) là một hệ thống phân tán hỗ trợ mở rộng quy mô theo chiều ngang, tức là sharding; và trong mỗi phân đoạn, nó cũng hỗ trợ dự phòng dữ liệu, tức là sao chép.
Sharding trong MongoDB (không phải cơ sở dữ liệu quan hệ) thực hiện cân bằng tự động, nghĩa là mỗi bộ sưu tập tài liệu (hoặc “bảng” theo dữ liệu quan hệ) được chia thành nhiều phần và máy chủ sẽ tự động di chuyển chúng giữa các phân đoạn.
Bộ định tuyến truy vấn, nơi phân phối các yêu cầu, cho một máy khách là một số máy khách mà nó hoạt động thông qua đó. Nó đã biết vị trí và dữ liệu nào được đặt và chuyển tất cả các yêu cầu đến phân đoạn chính xác.
Một điểm quan trọng khác: MongoDB là một master duy nhất. Có một Chính - nó có thể lấy các bản ghi hỗ trợ các khóa mà nó chứa. Bạn không thể viết Multi-master.
Chúng tôi đã phát hành phiên bản 4.2 - những điều thú vị mới đã xuất hiện ở đó. Đặc biệt, họ đã chèn Lucene - tìm kiếm - cụ thể là java thực thi trực tiếp vào Mongo và ở đó có thể thực hiện tìm kiếm thông qua Lucene, giống như trong Elastica.
Và họ đã tạo ra một sản phẩm mới - Biểu đồ, nó cũng có sẵn trên Atlas (Đám mây của riêng Mongo). Họ có Bậc miễn phí - bạn có thể tùy ý sử dụng nó. Tôi thực sự thích Biểu đồ - trực quan hóa dữ liệu, rất trực quan.
Thành phần Tính nhất quán của nguyên nhân
Tôi đếm được khoảng 230 bài báo đã được xuất bản về chủ đề này - của Leslie Lampert. Bây giờ theo trí nhớ của tôi, tôi sẽ truyền đạt cho các bạn một số phần của những tài liệu này.
Mọi chuyện bắt đầu từ một bài báo của Leslie Lampert, được viết vào những năm 1970. Như bạn có thể thấy, một số nghiên cứu về chủ đề này vẫn đang được tiến hành. Hiện nay, tính nhất quán của nguyên nhân đang được quan tâm liên quan đến sự phát triển của các hệ thống phân tán.
Hạn chế
Có những hạn chế gì? Đây thực sự là một trong những điểm chính, bởi vì những hạn chế mà hệ thống sản xuất áp đặt rất khác với những hạn chế tồn tại trong các bài báo học thuật. Chúng thường khá nhân tạo.
- Đầu tiên, “MongoDB” là một master duy nhất, như tôi đã nói (điều này giúp đơn giản hóa rất nhiều).
- Chúng tôi tin rằng hệ thống sẽ hỗ trợ khoảng 10 nghìn phân đoạn. Chúng tôi không thể đưa ra bất kỳ quyết định kiến trúc nào sẽ giới hạn giá trị này một cách rõ ràng.
- Chúng tôi có một đám mây, nhưng chúng tôi cho rằng một người vẫn có cơ hội khi anh ta tải xuống tệp nhị phân, chạy nó trên máy tính xách tay của mình và mọi thứ đều hoạt động tốt.
- Chúng tôi giả định một điều mà Nghiên cứu hiếm khi giả định: khách hàng bên ngoài có thể làm bất cứ điều gì họ muốn. MongoDB là nguồn mở. Theo đó, khách hàng có thể rất thông minh và nóng nảy - họ có thể muốn phá vỡ mọi thứ. Chúng tôi suy đoán rằng Byzantine Feilors có thể bắt nguồn.
- Đối với các máy khách bên ngoài nằm ngoài phạm vi, có một hạn chế quan trọng: nếu tính năng này bị tắt thì sẽ không thấy hiện tượng suy giảm hiệu suất.
- Một điểm khác nói chung là phản học thuật: tính tương thích của các phiên bản trước và phiên bản tương lai. Trình điều khiển cũ phải hỗ trợ các bản cập nhật mới và cơ sở dữ liệu phải hỗ trợ trình điều khiển cũ.
Nói chung, tất cả điều này đặt ra những hạn chế.
Các thành phần nhất quán nhân quả
Bây giờ tôi sẽ nói về một số thành phần. Nếu chúng ta xem xét tính nhất quán của Nguyên nhân nói chung, chúng ta có thể chọn các khối. Chúng tôi đã chọn từ các tác phẩm thuộc một khối nhất định: Theo dõi phụ thuộc, chọn đồng hồ, cách các đồng hồ này có thể được đồng bộ hóa với nhau và cách chúng tôi đảm bảo bảo mật - đây là tóm tắt sơ bộ về những gì tôi sẽ nói:
Theo dõi phụ thuộc đầy đủ
Tại sao nó lại cần thiết? Vì vậy, khi dữ liệu được sao chép, mỗi bản ghi, mỗi thay đổi dữ liệu đều chứa thông tin về những thay đổi mà nó phụ thuộc vào. Thay đổi đầu tiên và đơn giản nhất là khi mỗi tin nhắn chứa một bản ghi chứa thông tin về các tin nhắn trước đó:
Trong ví dụ này, số trong ngoặc nhọn là số bản ghi. Đôi khi những bản ghi có giá trị này thậm chí còn được chuyển toàn bộ, đôi khi một số phiên bản cũng được chuyển. Điểm mấu chốt là mỗi thay đổi đều chứa thông tin về thay đổi trước đó (rõ ràng là chứa đựng tất cả những điều này trong chính nó).
Tại sao chúng tôi quyết định không sử dụng phương pháp này (theo dõi đầy đủ)? Rõ ràng, bởi vì cách tiếp cận này không thực tế: mọi thay đổi đối với mạng xã hội đều phụ thuộc vào tất cả những thay đổi trước đó đối với mạng xã hội đó, chẳng hạn như việc chuyển Facebook hoặc VKontakte trong mỗi bản cập nhật. Tuy nhiên, có rất nhiều nghiên cứu về Theo dõi phụ thuộc hoàn toàn - đây là những mạng xã hội chưa có; đối với một số trường hợp, nó thực sự hiệu quả.
Theo dõi phụ thuộc rõ ràng
Cái tiếp theo thì hạn chế hơn. Việc chuyển thông tin cũng được xem xét ở đây, nhưng chỉ những thông tin phụ thuộc rõ ràng. Điều gì phụ thuộc vào điều gì, theo quy định, được xác định bởi Ứng dụng. Khi dữ liệu được sao chép, truy vấn chỉ trả về phản hồi khi các phần phụ thuộc trước đó đã được thỏa mãn, nghĩa là được hiển thị. Đây là bản chất của cách thức hoạt động của tính nhất quán Nhân quả.
Cô ấy thấy rằng bản ghi 5 phụ thuộc vào các bản ghi 1, 2, 3, 4 - theo đó, cô ấy đợi trước khi khách hàng có quyền truy cập vào các thay đổi do quyết định truy cập của Penny thực hiện, khi tất cả các thay đổi trước đó đã đi qua cơ sở dữ liệu.
Điều này cũng không phù hợp với chúng tôi vì vẫn còn quá nhiều thông tin và nó sẽ làm mọi thứ chậm lại. Có một cách tiếp cận khác...
Đồng hồ Lamport
Họ rất già. Đồng hồ Lamport có nghĩa là các phần phụ thuộc này được xếp thành một hàm vô hướng, được gọi là Đồng hồ Lamport.
Hàm vô hướng là một số trừu tượng. Nó thường được gọi là thời gian logic. Với mỗi sự kiện, bộ đếm này sẽ tăng lên. Bộ đếm, hiện đã được biết đến với quy trình, sẽ gửi từng tin nhắn. Rõ ràng là các quy trình có thể không đồng bộ, chúng có thể có thời gian hoàn toàn khác nhau. Tuy nhiên, bằng cách nào đó hệ thống đã cân bằng đồng hồ với những tin nhắn như vậy. Điều gì xảy ra trong trường hợp này?
Tôi chia phân đoạn lớn đó thành hai để làm rõ: Bạn bè có thể nằm trong một nút chứa một phần của bộ sưu tập và Nguồn cấp dữ liệu có thể nằm trong một nút khác chứa một phần của bộ sưu tập này. Có rõ ràng làm thế nào họ có thể thoát khỏi dòng? Nguồn cấp dữ liệu đầu tiên sẽ có nội dung: “Đã sao chép”, sau đó là Bạn bè. Nếu hệ thống không cung cấp một số loại đảm bảo rằng Nguồn cấp dữ liệu sẽ không được hiển thị cho đến khi các phần phụ thuộc Bạn bè trong bộ sưu tập Bạn bè cũng được phân phối, thì chúng ta sẽ gặp phải tình huống chính xác mà tôi đã đề cập.
Bạn thấy thời gian truy cập trên Feed tăng lên một cách hợp lý như thế nào:
Vì vậy, đặc tính chính của Đồng hồ Lamport và tính nhất quán của Nguyên nhân (được giải thích thông qua Đồng hồ Lamport) là thế này: nếu chúng ta có Sự kiện A và B và Sự kiện B phụ thuộc vào Sự kiện A*, thì theo đó Thời gian Hợp lý của Sự kiện A nhỏ hơn Thời gian logic từ sự kiện B.
* Đôi khi người ta còn nói A xảy ra trước B, tức là A xảy ra trước B - đây là một mối quan hệ nhất định sắp xếp một phần cho toàn bộ tập hợp các sự kiện xảy ra nói chung.
Điều ngược lại là không đúng. Đây thực sự là một trong những nhược điểm chính của Đồng hồ Lamport - trật tự một phần. Có một khái niệm về các sự kiện xảy ra đồng thời, tức là các sự kiện trong đó không (A xảy ra trước B) cũng không (A xảy ra trước B). Một ví dụ sẽ là việc Leonard song song bổ sung một người khác làm bạn (thậm chí không phải Leonard mà là Sheldon chẳng hạn).
Đây là đặc tính thường được sử dụng khi làm việc với đồng hồ Lamport: họ xem xét cụ thể chức năng và từ đó kết luận rằng có lẽ những sự kiện này phụ thuộc vào nhau. Bởi vì có một cách đúng: nếu LogicalTime A nhỏ hơn LogicalTime B thì B không thể xảy ra trước A; và nếu nhiều hơn thì có thể.
Đồng Hồ Vector
Sự phát triển hợp lý của đồng hồ Lamport là Đồng hồ Vector. Chúng khác nhau ở chỗ mỗi nút ở đây chứa đồng hồ riêng và chúng được truyền dưới dạng vectơ.
Trong trường hợp này, bạn thấy rằng chỉ mục thứ 1 của vectơ chịu trách nhiệm về Nguồn cấp dữ liệu và chỉ mục đầu tiên của vectơ là dành cho Bạn bè (mỗi nút này). Và bây giờ chúng sẽ tăng: chỉ số 2 của “Feed” tăng khi viết – 3, XNUMX, XNUMX:
Tại sao Đồng hồ Vector tốt hơn? Bởi vì chúng cho phép bạn tìm ra sự kiện nào xảy ra đồng thời và khi nào chúng xảy ra trên các nút khác nhau. Điều này rất quan trọng đối với một hệ thống sharding như MongoDB. Tuy nhiên, chúng tôi đã không chọn điều này, mặc dù nó là một điều tuyệt vời, nó hoạt động rất tốt và có lẽ nó sẽ phù hợp với chúng tôi...
Nếu chúng ta có 10 nghìn phân đoạn, chúng ta không thể chuyển 10 nghìn thành phần, ngay cả khi chúng ta nén nó hoặc nghĩ ra thứ gì khác - tải trọng vẫn sẽ nhỏ hơn vài lần so với âm lượng của toàn bộ vectơ này. Vì vậy, nghiến răng nghiến lợi, chúng tôi từ bỏ cách này và chuyển sang cách khác.
Cờ lê TrueTime. Đồng hồ nguyên tử
Tôi đã nói sẽ có một câu chuyện về Spanner. Đây là một điều tuyệt vời, xuất phát từ thế kỷ XNUMX: đồng hồ nguyên tử, đồng bộ hóa GPS.
Ý tưởng là gì? “Spanner” là một hệ thống của Google gần đây thậm chí còn được cung cấp cho mọi người (họ đã thêm SQL vào đó). Mỗi giao dịch có một số dấu thời gian. Vì thời gian được đồng bộ hóa*, nên mỗi sự kiện có thể được ấn định một thời gian cụ thể - đồng hồ nguyên tử có thời gian chờ, sau đó đảm bảo sẽ “xảy ra” một thời gian khác.
Do đó, chỉ cần ghi vào cơ sở dữ liệu và chờ một khoảng thời gian, Khả năng tuần tự hóa của sự kiện sẽ tự động được đảm bảo. Họ có mô hình nhất quán mạnh nhất có thể hình dung được về nguyên tắc - đó là tính nhất quán bên ngoài.
* Đây là vấn đề chính với đồng hồ Lampart - chúng không bao giờ đồng bộ trên hệ thống phân tán. Chúng có thể khác nhau, ngay cả với NTP, chúng vẫn hoạt động không tốt lắm. "Spanner" có đồng hồ nguyên tử và sự đồng bộ hóa dường như là micro giây.
Tại sao chúng ta không chọn? Chúng tôi không cho rằng người dùng của chúng tôi có đồng hồ nguyên tử tích hợp. Khi chúng xuất hiện, được tích hợp vào mọi máy tính xách tay, sẽ có một số loại đồng bộ hóa GPS cực hay - thì đúng vậy... Nhưng hiện tại, thứ tốt nhất có thể là Amazon, Base Stations - dành cho những người cuồng tín... Vì vậy, chúng tôi đã sử dụng những chiếc đồng hồ khác .
Đồng hồ lai
Đây thực sự là những gì cần lưu ý trong MongoDB khi đảm bảo tính nhất quán của Nguyên nhân. Chúng lai như thế nào? Kết hợp là một giá trị vô hướng nhưng nó có hai thành phần:
- Đầu tiên là kỷ nguyên Unix (đã bao nhiêu giây trôi qua kể từ “sự khởi đầu của thế giới máy tính”).
- Thứ hai là một số gia số, cũng là int không dấu 32 bit.
Thực ra đó là tất cả. Có cách tiếp cận này: bộ phận chịu trách nhiệm về thời gian luôn được đồng bộ hóa với đồng hồ; Mỗi khi có bản cập nhật xảy ra, phần này được đồng bộ hóa với đồng hồ và hóa ra thời gian luôn chính xác ít nhiều và mức tăng cho phép bạn phân biệt giữa các sự kiện xảy ra tại cùng một thời điểm.
Tại sao điều này lại quan trọng đối với MongoDB? Bởi vì nó cho phép bạn tạo một số loại nhà hàng dự phòng tại một thời điểm nhất định, tức là sự kiện được lập chỉ mục theo thời gian. Điều này rất quan trọng khi cần một số sự kiện nhất định; Đối với cơ sở dữ liệu, sự kiện là những thay đổi trong cơ sở dữ liệu xảy ra ở những khoảng thời gian nhất định.
Tôi sẽ chỉ cho bạn biết lý do quan trọng nhất (làm ơn đừng nói cho ai biết)! Chúng tôi làm điều này vì đây là dữ liệu được lập chỉ mục và có tổ chức trong MongoDB OpLog. OpLog là cấu trúc dữ liệu chứa tất cả các thay đổi trong cơ sở dữ liệu: trước tiên chúng chuyển đến OpLog, sau đó chúng được áp dụng cho chính Bộ lưu trữ trong trường hợp đó là ngày hoặc phân đoạn được sao chép.
Đây là lý do chính. Tuy nhiên, cũng có những yêu cầu thực tế để phát triển cơ sở dữ liệu, có nghĩa là nó phải đơn giản - ít mã, càng ít thứ hỏng hóc cần được viết lại và kiểm tra càng tốt. Việc các oplog của chúng tôi được lập chỉ mục bởi đồng hồ lai đã giúp ích rất nhiều và cho phép chúng tôi đưa ra lựa chọn đúng đắn. Nó thực sự đã được đền đáp và bằng cách nào đó đã hoạt động một cách kỳ diệu trên nguyên mẫu đầu tiên. Nó rất mát mẻ!
Đồng bộ hóa đồng hồ
Có một số phương pháp đồng bộ hóa được mô tả trong tài liệu khoa học. Tôi đang nói về việc đồng bộ hóa khi chúng tôi có hai phân đoạn khác nhau. Nếu có một bộ bản sao thì không cần bất kỳ sự đồng bộ hóa nào: đây là một “bản gốc duy nhất”; chúng tôi có OpLog, nơi chứa tất cả các thay đổi - trong trường hợp này, mọi thứ đã được sắp xếp tuần tự trong chính “Oplog”. Nhưng nếu chúng ta có hai phân đoạn khác nhau thì việc đồng bộ hóa thời gian ở đây rất quan trọng. Đây là nơi mà đồng hồ vector đã giúp ích nhiều hơn! Nhưng chúng tôi không có chúng.
Cái thứ hai phù hợp - đây là "Heartbeats". Có thể trao đổi một số tín hiệu xảy ra trong mỗi đơn vị thời gian. Nhưng Nhịp tim quá chậm nên chúng tôi không thể cung cấp độ trễ cho khách hàng của mình.
Tất nhiên, thời gian thực sự là một điều tuyệt vời. Tuy nhiên, một lần nữa, đây có lẽ là tương lai... Mặc dù điều này đã có thể được thực hiện trong Atlas nhưng hiện đã có những bộ đồng bộ hóa thời gian nhanh chóng trên “Amazon”. Nhưng nó sẽ không có sẵn cho tất cả mọi người.
Tán gẫu là khi tất cả các tin nhắn đều có thời gian. Đây là khoảng những gì chúng tôi sử dụng. Mọi thông báo giữa các nút, trình điều khiển, bộ định tuyến nút dữ liệu, tất cả mọi thứ đối với MongoDB đều là một loại phần tử nào đó, một thành phần cơ sở dữ liệu có chứa đồng hồ chạy. Chúng mang ý nghĩa lai ghép thời gian ở khắp mọi nơi, nó được truyền đi. 64 bit? Điều này cho phép, điều này là có thể.
Làm thế nào để tất cả làm việc cùng nhau?
Ở đây tôi đang xem xét một bộ bản sao để làm cho nó dễ dàng hơn một chút. Có Tiểu học và Trung học. Thứ cấp thực hiện sao chép và không phải lúc nào cũng được đồng bộ hóa hoàn toàn với Chính.
Việc chèn xảy ra vào “Primery” với một giá trị thời gian nhất định. Phần chèn này tăng số lượng bên trong lên 11, nếu đây là mức tối đa. Hoặc nó sẽ kiểm tra các giá trị đồng hồ và đồng bộ với đồng hồ nếu giá trị đồng hồ lớn hơn. Điều này cho phép bạn tổ chức theo thời gian.
Sau khi anh ấy ghi âm, một khoảnh khắc quan trọng sẽ xảy ra. Đồng hồ ở "MongoDB" và chỉ tăng trong trường hợp ghi vào "Oplog". Đây là sự kiện làm thay đổi trạng thái của hệ thống. Trong tất cả các bài viết cổ điển, một sự kiện được coi là khi một tin nhắn chạm vào một nút: tin nhắn đã đến, có nghĩa là hệ thống đã thay đổi trạng thái.
Điều này là do thực tế là trong quá trình nghiên cứu, vẫn chưa hoàn toàn rõ ràng thông điệp này sẽ được giải thích như thế nào. Chúng tôi biết chắc chắn rằng nếu nó không được phản ánh trong “Oplog”, thì nó sẽ không được giải thích theo bất kỳ cách nào và sự thay đổi trạng thái của hệ thống chỉ là một mục trong “Oplog”. Điều này đơn giản hóa mọi thứ cho chúng ta: mô hình đơn giản hóa nó và cho phép chúng ta sắp xếp nó trong một bộ bản sao và nhiều thứ hữu ích khác.
Giá trị đã được ghi vào “Oplog” được trả về - chúng ta biết rằng “Oplog” đã chứa giá trị này và thời gian của nó là 12. Bây giờ, giả sử, việc đọc bắt đầu từ một nút khác (Phụ) và nó truyền afterClusterTime trong thông điệp. Anh ấy nói: “Tôi cần mọi thứ xảy ra ít nhất sau 12 giờ hoặc trong XNUMX giờ” (xem hình trên).
Đây là cái được gọi là Nguyên nhân nhất quán (CAT). Về mặt lý thuyết, có một khái niệm cho rằng đây là một khoảng thời gian nào đó, bản thân nó nhất quán. Trong trường hợp này, chúng ta có thể nói rằng đây là trạng thái của hệ thống được quan sát tại thời điểm 12.
Hiện tại vẫn chưa có gì ở đây vì kiểu này mô phỏng tình huống khi bạn cần Thứ cấp để sao chép dữ liệu từ Chính. Anh ấy đợi... Và bây giờ dữ liệu đã đến - anh ấy trả lại những giá trị này.
Đó gần như là cách mọi thứ hoạt động. Hầu hết.
"gần như" nghĩa là gì? Giả sử rằng có một số người đã đọc và hiểu cách hoạt động của tất cả những điều này. Tôi nhận ra rằng mỗi khi ClusterTime xảy ra, nó sẽ cập nhật đồng hồ logic bên trong và sau đó mục tiếp theo sẽ tăng thêm một. Hàm này có 20 dòng. Giả sử người này truyền số 64 bit lớn nhất, trừ đi một.
Tại sao lại "trừ một"? Bởi vì đồng hồ bên trong sẽ được thay thế bằng giá trị này (rõ ràng đây là giá trị lớn nhất có thể và lớn hơn thời gian hiện tại), khi đó một mục nhập sẽ xuất hiện trong “Oplog” và đồng hồ sẽ được tăng thêm một đơn vị khác - và sẽ có là giá trị tối đa (đơn giản là có tất cả các đơn vị, không còn nơi nào khác để đi), số nguyên không rõ ràng).
Rõ ràng là sau đó hệ thống hoàn toàn không thể tiếp cận được với bất kỳ thứ gì. Nó chỉ có thể được dỡ ra và làm sạch - rất nhiều công việc thủ công. Sẵn có đầy đủ:
Hơn nữa, nếu điều này được sao chép ở một nơi khác thì toàn bộ cụm sẽ bị loại bỏ. Một tình huống hoàn toàn không thể chấp nhận được mà bất cứ ai cũng có thể tổ chức rất nhanh chóng và dễ dàng! Vì vậy, chúng tôi coi thời điểm này là một trong những thời điểm quan trọng nhất. Làm thế nào để ngăn chặn nó?
Cách của chúng tôi là ký clusterTime
Đây là cách nó được truyền đi trong tin nhắn (trước dòng chữ màu xanh lam). Nhưng chúng tôi cũng bắt đầu tạo chữ ký (văn bản màu xanh):
Chữ ký được tạo bởi một khóa được lưu trữ bên trong cơ sở dữ liệu, bên trong phạm vi bảo mật; chính nó được tạo và cập nhật (người dùng không thấy gì về nó). Một hàm băm được tạo và mỗi tin nhắn được ký khi được tạo và xác thực khi nhận được.
Câu hỏi có lẽ nảy sinh trong đầu mọi người: “Điều này làm mọi thứ chậm lại bao nhiêu?” Tôi đã nói với bạn rằng nó sẽ hoạt động nhanh chóng, đặc biệt khi không có tính năng này.
Việc sử dụng tính nhất quán Nhân quả trong trường hợp này có ý nghĩa gì? Điều này nhằm hiển thị tham số afterClusterTime. Nếu không có điều này, nó sẽ chỉ truyền các giá trị. Chuyện phiếm, bắt đầu từ phiên bản 3.6, luôn có tác dụng.
Nếu chúng tôi để việc tạo chữ ký liên tục, nó sẽ làm chậm hệ thống ngay cả khi không có tính năng nào không đáp ứng được các phương pháp và yêu cầu của chúng tôi. Vậy chúng ta đã làm gì?
Làm điều đó một cách nhanh chóng!
Đó là một điều khá đơn giản, nhưng thủ thuật lại thú vị – tôi sẽ chia sẻ nó, có thể ai đó sẽ quan tâm.
Chúng tôi có một hàm băm lưu trữ dữ liệu đã ký. Tất cả dữ liệu đi qua bộ đệm. Bộ đệm không ký thời gian cụ thể mà là Phạm vi. Khi một số giá trị đến, chúng tôi tạo một Phạm vi, che đi 16 bit cuối cùng và chúng tôi ký giá trị này:
Bằng cách nhận được chữ ký như vậy, chúng tôi tăng tốc hệ thống (tương đối) 65 nghìn lần. Nó hoạt động rất tốt: khi chúng tôi tiến hành thử nghiệm, thời gian thực sự đã giảm 10 nghìn lần khi chúng tôi thực hiện cập nhật tuần tự. Rõ ràng là khi họ xung đột, điều này không có tác dụng. Nhưng trong hầu hết các trường hợp thực tế, nó hoạt động. Sự kết hợp giữa chữ ký Range cùng với chữ ký đã giải quyết được vấn đề bảo mật.
Chúng ta đã học được gì?
Bài học chúng tôi học được từ điều này:
- Chúng ta cần đọc tài liệu, truyện, bài báo vì chúng ta có rất nhiều điều thú vị. Khi chúng tôi làm việc trên một số tính năng (đặc biệt là bây giờ, khi chúng tôi thực hiện giao dịch, v.v.), chúng tôi cần đọc và hiểu. Việc này tốn thời gian nhưng thực sự rất hữu ích vì nó cho thấy rõ chúng ta đang ở đâu. Chúng tôi dường như không nghĩ ra điều gì mới – chúng tôi chỉ lấy nguyên liệu.
Nhìn chung, có sự khác biệt nhất định trong suy nghĩ khi có một hội nghị học thuật (Sigmon chẳng hạn) - mọi người đều tập trung vào những ý tưởng mới. Thuật toán của chúng tôi có gì mới? Không có sự mới lạ đặc biệt ở đây. Điểm mới lạ nằm ở cách chúng tôi kết hợp các phương pháp tiếp cận hiện có với nhau. Vì vậy, việc đầu tiên là đọc những tác phẩm kinh điển, bắt đầu từ Lampart.
- Trong sản xuất, các yêu cầu hoàn toàn khác nhau. Tôi chắc chắn rằng nhiều người trong số các bạn không phải đối mặt với cơ sở dữ liệu “hình cầu” trong chân không trừu tượng, mà với những thứ thực tế, bình thường có vấn đề về tính khả dụng, độ trễ và khả năng chịu lỗi.
- Điều cuối cùng là chúng tôi phải xem xét các ý tưởng khác nhau và kết hợp nhiều bài viết hoàn toàn khác nhau thành một cách tiếp cận cùng nhau. Ví dụ: ý tưởng về việc ký thường xuất phát từ một bài viết coi giao thức Paxos, giao thức dành cho những Người thất bại không phải Byzantine nằm trong giao thức ủy quyền, đối với những người Byzantine - nằm ngoài giao thức ủy quyền... Nói chung, đây chính xác là những gì chúng tôi cuối cùng đã làm.
Hoàn toàn không có gì mới ở đây! Nhưng ngay khi chúng tôi trộn tất cả lại với nhau... Cũng giống như nói rằng công thức món salad Olivier là vô nghĩa, bởi vì trứng, sốt mayonnaise và dưa chuột đã được phát minh ra rồi... Đó là về cùng một câu chuyện.
Tôi sẽ kết thúc với điều này. Cảm ơn!
câu hỏi
Câu hỏi của khán giả (sau đây gọi là B): – Cảm ơn Mikhail vì đã báo cáo! Chủ đề về thời gian thật thú vị. Bạn đang sử dụng tin đồn. Họ nói rằng mọi người đều có thời gian riêng, mọi người đều biết giờ địa phương của mình. Theo tôi hiểu, chúng tôi có một trình điều khiển - có thể có nhiều khách hàng có trình điều khiển, người lập kế hoạch truy vấn, phân đoạn nữa... Và hệ thống sẽ gặp vấn đề gì nếu chúng tôi đột nhiên có sự khác biệt: ai đó quyết định rằng đó là dành cho một đi trước một phút, có người đi sau một phút? Chúng ta sẽ kết thúc ở đâu?
MT: – Câu hỏi hay thật đấy! Tôi chỉ muốn nói về những mảnh vỡ. Nếu hiểu đúng câu hỏi thì chúng ta gặp tình huống sau: có phân đoạn 1 và phân đoạn 2, việc đọc diễn ra từ hai phân đoạn này - chúng có sự khác biệt, chúng không tương tác với nhau, vì thời gian mà chúng biết là khác nhau, đặc biệt là thời gian chúng tồn tại trong oplog.
Giả sử rằng phân đoạn 1 đã tạo ra một triệu bản ghi, phân đoạn 2 không làm gì cả và yêu cầu được gửi đến hai phân đoạn. Và cái đầu tiên có afterClusterTime hơn một triệu. Trong tình huống như vậy, như tôi đã giải thích, phân đoạn 2 sẽ không bao giờ phản hồi.
В: – Tôi muốn biết họ đồng bộ hóa và chọn XNUMX thời gian hợp lý như thế nào?
MT: - Rất dễ dàng để đồng bộ hóa. Shard, khi afterClusterTime đến với anh ta và anh ta không tìm thấy thời gian trong “Oplog”, thì không được chấp thuận. Tức là anh ta nâng thời gian của mình bằng tay lên giá trị này. Điều này có nghĩa là không có sự kiện nào phù hợp với yêu cầu này. Anh ta tạo ra sự kiện này một cách giả tạo và do đó trở nên nhất quán nhân quả.
В: – Điều gì sẽ xảy ra nếu sau đó một số sự kiện khác đến với anh ta và bị thất lạc ở đâu đó trên mạng?
MT: – Shard được thiết kế theo cách mà chúng sẽ không xuất hiện nữa vì nó là một bản gốc duy nhất. Nếu anh ấy đã đăng ký rồi thì họ sẽ không đến mà sẽ đến sau. Không thể xảy ra chuyện có điều gì đó mắc kẹt ở đâu đó, rồi anh ta không viết, rồi những sự kiện này ập đến - và tính nhất quán của Nhân quả bị phá vỡ. Khi anh ấy không viết, tất cả họ sẽ đến tiếp theo (anh ấy sẽ đợi họ).
В: – Tôi có một số câu hỏi liên quan đến việc xếp hàng. Tính nhất quán nhân quả giả định rằng có một hàng hành động cụ thể cần được thực hiện. Điều gì xảy ra nếu một trong các gói của chúng tôi biến mất? Đây là ngày 10, 11... ngày 12 đã biến mất, và tất cả những người khác đang chờ đợi nó trở thành sự thật. Và đột nhiên xe của chúng tôi chết máy, chúng tôi không thể làm gì được. Có độ dài tối đa của hàng đợi được tích lũy trước khi được thực thi không? Thất bại nghiêm trọng nào xảy ra khi bất kỳ một trạng thái nào bị mất? Hơn nữa, nếu chúng ta viết ra rằng có một trạng thái nào đó trước đó, thì bằng cách nào đó chúng ta nên bắt đầu từ nó? Nhưng họ không đẩy anh ra!
MT: – Đây cũng là một câu hỏi hay! Chúng ta đang làm gì vậy? MongoDB có khái niệm về số đại biểu viết, số đại biểu đọc. Trong trường hợp nào tin nhắn có thể bị mất? Khi một lượt ghi không đủ số lượng hoặc khi một lượt đọc không đủ số lượng (một số loại rác cũng có thể dính vào).
Về tính nhất quán của Nguyên nhân, một thử nghiệm thử nghiệm lớn đã được thực hiện, kết quả là trong trường hợp ghi và đọc không đủ đại biểu, sẽ xảy ra vi phạm về tính nhất quán của Nguyên nhân. Chính xác những gì bạn nói!
Lời khuyên của chúng tôi: hãy sử dụng ít nhất số đại biểu khi sử dụng tính nhất quán của Nguyên nhân. Trong trường hợp này, sẽ không có gì bị mất, ngay cả khi bản ghi đại biểu bị mất... Đây là một tình huống trực giao: nếu người dùng không muốn mất dữ liệu thì cần sử dụng bản ghi đại biểu. Tính nhất quán nhân quả không đảm bảo độ bền. Độ bền được đảm bảo bằng sự nhân rộng và máy móc liên quan đến việc nhân rộng.
В: – Khi chúng ta tạo một phiên bản thực hiện sharding cho chúng ta (không phải chính mà là phụ), nó sẽ dựa vào thời gian Unix của máy của chính nó hoặc vào thời gian của “chính”; Nó đồng bộ lần đầu tiên hay định kỳ?
MT: – Bây giờ tôi sẽ làm rõ. Phân đoạn (tức là phân vùng ngang) – luôn có Chính ở đó. Và một phân đoạn có thể có “bản chính” và có thể có bản sao. Nhưng phân đoạn luôn hỗ trợ ghi vì nó phải hỗ trợ một số miền (phân đoạn có Chính).
В: – Vậy là mọi việc hoàn toàn phụ thuộc vào “chủ nhân”? Thời gian chủ có luôn được sử dụng không?
MT: - Đúng. Bạn có thể nói một cách hình tượng: đồng hồ đang tích tắc khi một mục nhập vào “master”, vào “Oplog” xảy ra.
В: – Chúng ta có khách hàng kết nối và không cần biết gì về thời gian?
MT: – Bạn không cần phải biết gì cả! Nếu chúng ta nói về cách nó hoạt động trên máy khách: khi khách hàng muốn sử dụng tính nhất quán Nhân quả, anh ta cần mở một phiên. Bây giờ mọi thứ đã có sẵn: các giao dịch trong phiên và lấy lại các quyền... Phiên là thứ tự của các sự kiện logic xảy ra với máy khách.
Nếu anh ấy mở phiên này và nói ở đó rằng anh ấy muốn tính nhất quán của Nhân quả (nếu phiên này hỗ trợ tính nhất quán của Nhân quả theo mặc định), thì mọi thứ sẽ hoạt động tự động. Trình điều khiển ghi nhớ thời gian này và tăng lên khi nhận được tin nhắn mới. Nó ghi nhớ phản hồi trước đó được trả về từ máy chủ trả về dữ liệu. Yêu cầu tiếp theo sẽ chứa afterCluster("thời gian lớn hơn thời gian này").
Khách hàng không cần phải biết hoàn toàn bất cứ điều gì! Điều này hoàn toàn không rõ ràng đối với anh ta. Nếu mọi người sử dụng những tính năng này, họ có thể làm gì? Đầu tiên, bạn có thể đọc các thư mục phụ một cách an toàn: bạn có thể ghi vào Chính và đọc từ các thư mục phụ được sao chép về mặt địa lý và đảm bảo rằng nó hoạt động. Đồng thời, các phiên đã được ghi lại trên Chính thậm chí có thể được chuyển sang Trung học, tức là bạn không thể sử dụng một phiên mà nhiều phiên.
В: – Một lớp mới của Khoa học máy tính – loại dữ liệu CRDT (Các loại dữ liệu được sao chép không xung đột) – có liên quan chặt chẽ đến chủ đề Tính nhất quán cuối cùng. Bạn đã cân nhắc việc tích hợp các loại dữ liệu này vào cơ sở dữ liệu chưa và bạn có thể nói gì về nó?
MT: - Câu hỏi hay! CRDT có ý nghĩa đối với xung đột ghi: trong MongoDB, một bản gốc.
В: – Tôi có một câu hỏi từ các devops. Trong thế giới thực, có những tình huống Dòng Tên như vậy khi Thất bại của Byzantine xảy ra và những kẻ xấu xa bên trong vành đai được bảo vệ bắt đầu xâm nhập vào giao thức, gửi các gói hàng thủ công theo một cách đặc biệt?
MT: – Kẻ ác ở trong vành đai giống như ngựa thành Troy! Kẻ ác ở trong vành đai có thể làm rất nhiều điều xấu.
В: – Nói một cách đại khái, rõ ràng là việc để lại một lỗ hổng trên máy chủ mà qua đó bạn có thể đặt một vườn thú voi và đánh sập toàn bộ cụm mãi mãi... Sẽ mất thời gian để khôi phục thủ công... Nói một cách nhẹ nhàng thì điều này là sai. Mặt khác, điều này thật thú vị: trong đời thực, trong thực tế, có những tình huống xảy ra các cuộc tấn công nội bộ tương tự một cách tự nhiên?
MT: – Vì tôi hiếm khi gặp phải các vi phạm an ninh trong đời thực nên tôi không thể nói liệu chúng có xảy ra hay không. Nhưng nếu nói về triết lý phát triển, chúng tôi nghĩ như thế này: chúng tôi có một vành đai cung cấp cho những người làm nhiệm vụ an ninh - đây là một lâu đài, một bức tường; và bên trong chu vi bạn có thể làm bất cứ điều gì bạn muốn. Rõ ràng là có những người dùng có khả năng chỉ xem và có những người dùng có khả năng xóa thư mục.
Tùy theo quyền mà thiệt hại mà người dùng có thể gây ra có thể là chuột hoặc có thể là voi. Rõ ràng là người dùng có toàn quyền có thể làm bất cứ điều gì. Người dùng bị hạn chế quyền có thể gây ra ít tác hại hơn đáng kể. Đặc biệt, nó không thể phá vỡ hệ thống.
В: – Trong phạm vi được bảo vệ, ai đó đã cố gắng tạo các giao thức không mong muốn cho máy chủ nhằm phá hủy hoàn toàn máy chủ và nếu bạn may mắn, toàn bộ cụm… Liệu nó có bao giờ đạt được điều đó “tốt” không?
MT: “Tôi chưa bao giờ nghe nói về những điều như vậy.” Việc bạn có thể làm sập máy chủ theo cách này không có gì là bí mật. Thất bại bên trong, xuất phát từ giao thức, là người dùng được ủy quyền có thể viết nội dung như thế này trong tin nhắn... Trên thực tế, điều đó là không thể, vì nó vẫn sẽ được xác minh. Có thể vô hiệu hóa xác thực này đối với những người dùng không muốn - đó là vấn đề của họ; Nói một cách đại khái, họ đã tự phá hủy các bức tường và bạn có thể đẩy một con voi vào đó, nó sẽ giẫm đạp... Nhưng nói chung, bạn có thể hóa trang thành thợ sửa chữa, đến và kéo nó ra!
В: – Cảm ơn vì đã báo cáo. Serge (Yandex). Có một hằng số trong Mong giới hạn số lượng thành viên biểu quyết trong Bộ bản sao và hằng số này là 7 (bảy). Tại sao điều này là một hằng số? Tại sao đây không phải là một loại tham số?
MT: – Chúng tôi có Bộ bản sao với 40 nút. Luôn luôn có đa số. Tôi không biết phiên bản nào ...
В: – Trong Replica Set bạn có thể chạy các thành viên không có quyền biểu quyết, nhưng có tối đa 7 thành viên có quyền biểu quyết. Làm thế nào chúng ta có thể sống sót sau khi tắt máy trong trường hợp này nếu Bộ bản sao của chúng ta trải rộng trên 3 trung tâm dữ liệu? Một trung tâm dữ liệu có thể dễ dàng tắt và một máy khác có thể bị hỏng.
MT: – Chuyện này đã hơi vượt quá phạm vi của báo cáo rồi. Đây là một câu hỏi chung. Có lẽ tôi có thể kể cho bạn nghe về nó sau.
Một số quảng cáo 🙂
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com