Thực đơn
trang chủiOS

Chia tỷ lệ theo chiều dọc và chiều ngang, chia tỷ lệ cho web. Tác động của kiến ​​trúc đến khả năng tiếp cận. Vấn đề chia tỷ lệ theo chiều dọc

Mọi lập trình viên đều muốn trở thành người giỏi nhất, ngày càng nhận được nhiều điều thú vị hơn và các nhiệm vụ phức tạp và giải quyết chúng ngày càng nhiều theo những cách hiệu quả. Trong thế giới phát triển Internet, những nhiệm vụ như vậy bao gồm cả những nhiệm vụ mà các nhà phát triển hệ thống có tải trọng cao phải đối mặt.

Hầu hết các thông tin đăng tải về chủ đề tải cao trên Internet chỉ là mô tả đặc điểm kỹ thuật hệ thống lớn. Chúng tôi sẽ cố gắng phác thảo các nguyên tắc xây dựng kiến ​​trúc của các dự án Internet tiên tiến nhất và được truy cập nhiều nhất trong thời đại chúng ta.

  • Tách chức năng
  • Chia tỷ lệ ngang cổ điển
    • Không chia sẻ gì và các khái niệm không quốc tịch
    • Sự chỉ trích về khái niệm Không chia sẻ và Không quốc tịch
    • Sự gắn kết giữa mã và dữ liệu
  • Bộ nhớ đệm
    • Vấn đề vô hiệu hóa bộ đệm
    • Sự cố bắt đầu với bộ đệm nguội

Hãy bắt đầu bài học thứ ba, dành riêng cho logic nghiệp vụ của dự án. Đây là thành phần quan trọng nhất trong việc xử lý bất kỳ yêu cầu nào. Những tính toán như vậy yêu cầu phụ trợ - máy chủ hạng nặng có sức mạnh tính toán lớn. Nếu giao diện người dùng không thể tự mình cung cấp thứ gì đó cho khách hàng (và như chúng tôi đã tìm ra ở vấn đề trước, chúng tôi có thể cung cấp thứ đó cho khách hàng mà không gặp bất kỳ vấn đề gì, chẳng hạn như hình ảnh), thì nó sẽ đưa ra yêu cầu cho giao diện người dùng . Ở phần phụ trợ, logic nghiệp vụ được xử lý, nghĩa là dữ liệu được tạo và xử lý, trong khi dữ liệu được lưu trữ ở một lớp khác - lưu trữ mạng, cơ sở dữ liệu hoặc hệ thống tập tin. Lưu trữ dữ liệu là chủ đề của bài học tiếp theo, nhưng hôm nay chúng ta sẽ tập trung vào việc mở rộng quy mô phần phụ trợ.

Hãy để chúng tôi cảnh báo bạn ngay lập tức: mở rộng quy mô phần phụ trợ điện toán là một trong những chủ đề khó, trong đó có rất nhiều huyền thoại. Điện toán đám mây giải quyết vấn đề hiệu suất - nhiều người chắc chắn như vậy. Tuy nhiên, điều này không hoàn toàn đúng: để bạn thực sự được giúp đỡ dịch vụ điện toán đám mây, bạn phải chuẩn bị mã chương trình của mình một cách chính xác. Bạn có thể thiết lập bao nhiêu máy chủ tùy thích trong Amazon EC2, nhưng chúng có ích gì nếu mã không thể sử dụng sức mạnh của từng máy chủ. Vậy làm thế nào để bạn mở rộng quy mô phụ trợ?

Tách chức năng

Phương pháp đầu tiên và đơn giản nhất mà mọi người gặp phải là phân vùng chức năng, trong đó các phần khác nhau của hệ thống, mỗi phần giải quyết nghiêm ngặt vấn đề riêng của mình, được tách thành các máy chủ vật lý riêng biệt. Ví dụ: diễn đàn bạn truy cập được chuyển đến một máy chủ và mọi thứ khác hoạt động trên máy chủ khác.

Mặc dù đơn giản nhưng nhiều người lại quên mất phương pháp này. Ví dụ: chúng tôi thường xuyên gặp các dự án web chỉ sử dụng một dự án Cơ sở dữ liệu MySQL hoàn toàn dưới Nhiều loại khác nhau dữ liệu. Cơ sở dữ liệu giống nhau chứa các bài viết, biểu ngữ và số liệu thống kê, mặc dù chúng phải khác nhau nếu có thiện chí Phiên bản MySQL. Nếu bạn có dữ liệu không liên quan đến chức năng (như trong ví dụ này), thì việc phân phối dữ liệu đó đến các phiên bản cơ sở dữ liệu khác nhau hoặc thậm chí cả máy chủ vật lý là điều hợp lý. Hãy nhìn vào điều này từ phía bên kia. Nếu bạn có cả công cụ quay vòng biểu ngữ tích hợp sẵn và dịch vụ hiển thị bài đăng của người dùng trong một dự án thì giải pháp hợp lý là ngay lập tức nhận ra rằng dữ liệu này không hề liên quan đến nhau và do đó phải tồn tại trong phiên bản đơn giản trong hai MySQL đang chạy khác nhau. Điều này cũng áp dụng cho các chương trình phụ trợ điện toán - chúng cũng có thể khác nhau. Với hoàn toàn cài đặt khác nhau, với các công nghệ khác nhau được sử dụng và viết bằng ngôn ngữ khác nhau lập trình. Quay lại ví dụ: để hiển thị các bài đăng, bạn có thể sử dụng PHP phổ biến nhất làm phụ trợ và đối với hệ thống biểu ngữ, bạn có thể chạy một mô-đun trên nginx. Theo đó, đối với các bài đăng bạn có thể phân bổ một máy chủ có một lượng lớn bộ nhớ (à, xét cho cùng thì cũng là PHP), trong khi đối với một hệ thống biểu ngữ, bộ nhớ có thể không quan trọng bằng dung lượng bộ xử lý.

Hãy rút ra kết luận: nên sử dụng phân vùng chức năng của phần phụ trợ làm phương pháp chia tỷ lệ đơn giản nhất. Nhóm các chức năng tương tự nhau và chạy các trình xử lý của chúng trên các nền tảng khác nhau. máy chủ vật lý. Hãy xem xét cách tiếp cận tiếp theo.

Từ các tác giả

Hoạt động chính của công ty chúng tôi là giải quyết các vấn đề liên quan đến với tải trọng cao, tư vấn, thiết kế kiến ​​trúc có thể mở rộng, tiến hành kiểm tra tải tối ưu hóa trang web. Khách hàng của chúng tôi bao gồm các nhà đầu tư từ Nga và trên toàn thế giới, cũng như các dự án “VKontakte”, “Eldorado”, “Imhonet”, Photosight.ru và các dự án khác. Trong quá trình tham vấn, chúng tôi thường nhận thấy rằng nhiều người không biết những điều cơ bản nhất - mở rộng quy mô là gì và nó diễn ra như thế nào, công cụ nào được sử dụng và để làm gì. Ấn phẩm này tiếp nối loạt bài “Hướng dẫn sử dụng tải cao" Trong các bài viết này, chúng tôi sẽ cố gắng nói một cách nhất quán về tất cả các công cụ được sử dụng để xây dựng kiến ​​trúc của các hệ thống tải cao.

Chia tỷ lệ ngang cổ điển

Về nguyên tắc, chúng ta đã biết chia tỷ lệ theo chiều ngang là gì. Nếu hệ thống của bạn không có đủ năng lượng, bạn chỉ cần thêm mười máy chủ nữa và chúng vẫn tiếp tục chạy. Nhưng không phải dự án nào cũng cho phép bạn làm điều này. Có một số mô hình cổ điển cần được xem xét sớm trong quá trình thiết kế để mã có thể mở rộng quy mô khi khối lượng công việc tăng lên.

Không chia sẻ gì và các khái niệm không quốc tịch

Hãy xem xét hai khái niệm - Không chia sẻ gì và Không trạng thái, có thể cung cấp khả năng mở rộng quy mô theo chiều ngang.

Cách tiếp cận Không chia sẻ có nghĩa là mỗi nút độc lập, tự cung cấp và không có điểm lỗi duy nhất. Tất nhiên, điều này không phải lúc nào cũng thực hiện được, nhưng trong mọi trường hợp, số lượng điểm như vậy đều nằm dưới sự kiểm soát chặt chẽ của kiến ​​​​trúc sư. Khi nói đến điểm không thành công, chúng tôi muốn nói đến một số dữ liệu hoặc phép tính chung cho tất cả các chương trình phụ trợ. Ví dụ: một số loại trình quản lý trạng thái hoặc mã định danh. Một ví dụ khác là việc sử dụng hệ thống tập tin mạng. Đây là cách trực tiếp để giải quyết nút thắt cổ chai trong kiến ​​trúc ở một giai đoạn phát triển dự án nhất định. Nếu mỗi nút độc lập thì chúng ta có thể dễ dàng thêm nhiều nút nữa khi tải tăng lên.

Khái niệm Không trạng thái có nghĩa là một tiến trình chương trình không lưu trữ trạng thái của chính nó. Người dùng đã đến và truy cập vào máy chủ cụ thể này và việc người dùng đến máy chủ này hay máy chủ khác không có gì khác biệt. Sau khi yêu cầu được xử lý, máy chủ này sẽ hoàn toàn quên thông tin về người dùng đó. Người dùng hoàn toàn không có nghĩa vụ phải gửi tất cả các yêu cầu tiếp theo của mình đến cùng một máy chủ và không cần phải đến cùng một máy chủ lần thứ hai. Do đó, chúng ta có thể thay đổi linh hoạt số lượng máy chủ và không phải lo lắng về việc định tuyến người dùng đến máy chủ mong muốn. Đây có lẽ là một trong những lý do chính khiến web phát triển nhanh chóng như vậy. Việc tạo các ứng dụng trong đó dễ dàng hơn nhiều so với việc viết các chương trình ngoại tuyến cổ điển. Khái niệm yêu cầu phản hồi và thực tế là chương trình của bạn tồn tại trong 200 mili giây hoặc tối đa một giây (sau đó nó bị phá hủy hoàn toàn) đã dẫn đến thực tế là các ngôn ngữ lập trình phổ biến như PHP vẫn không có trình thu gom rác.

Cách tiếp cận được mô tả là cổ điển: nó đơn giản và chắc chắn. Tuy nhiên, trong Gần đây chúng ta phải từ bỏ nó ngày càng thường xuyên hơn.

Sự chỉ trích về khái niệm Không chia sẻ và Không quốc tịch

Ngày nay, web phải đối mặt với những thách thức mới đặt ra những thách thức mới. Khi chúng tôi nói về Không trạng thái, điều này có nghĩa là chúng tôi vẽ lại mọi dữ liệu của từng người dùng từ bộ lưu trữ và việc này đôi khi có thể rất tốn kém. Có một mong muốn hợp lý là đưa một số dữ liệu vào bộ nhớ để làm cho nó không còn là trạng thái phi trạng thái nữa. Điều này là do ngày nay web ngày càng trở nên tương tác hơn. Nếu ngày hôm qua một người truy cập webmail và nhấp vào nút “Tải lại” để kiểm tra thư mới thì hôm nay máy chủ đã thực hiện việc này. Anh ta nói với anh ta: “Ồ, anh bạn, khi bạn đang ngồi trên trang này, bạn đã nhận được tin nhắn mới.”

Những thách thức mới nảy sinh có nghĩa là cách tiếp cận Không chia sẻ và phi trạng thái đôi khi không cần thiết. Chúng tôi đã nhiều lần gặp phải những tình huống với khách hàng mà chúng tôi nói: “Hãy từ bỏ việc này, đưa dữ liệu vào bộ nhớ” và ngược lại, “Hướng mọi người đến cùng một máy chủ”. Ví dụ: khi có một phòng trò chuyện mở, việc định tuyến mọi người đến cùng một máy chủ để tất cả hoạt động nhanh hơn là điều hợp lý.

Hãy nói về một trường hợp khác mà chúng tôi gặp phải. Một người bạn của chúng tôi đang phát triển một món đồ chơi như “Arena” (chiến đấu và chiến đấu trực tuyến) bằng Ruby on Rails. Ngay sau khi ra mắt, anh gặp phải vấn đề kinh điển: nếu có nhiều người tham gia cùng một trận chiến, mỗi người dùng sẽ liên tục lấy dữ liệu phát sinh trong trận chiến này ra khỏi cơ sở dữ liệu. Kết quả là toàn bộ cấu trúc này chỉ có thể tồn tại với tối đa 30 nghìn người dùng đã đăng ký và sau đó nó ngừng hoạt động.

Tình huống ngược lại đã xảy ra với công ty Vuga, công ty sản xuất trò chơi cho Facebook. Tuy nhiên, khi gặp phải một vấn đề tương tự, họ có quy mô khác: vài tỷ SELECT từ PostgreSQL mỗi ngày trên một hệ thống. Họ chuyển hoàn toàn sang cách tiếp cận Trạng thái bộ nhớ: dữ liệu bắt đầu được lưu trữ và phục vụ trực tiếp trong bộ nhớ truy cập tạm thời. Kết quả: những người này thực tế đã từ bỏ cơ sở dữ liệu và vài trăm máy chủ hóa ra là không cần thiết. Đơn giản là chúng đã bị tắt đi: chúng không còn cần thiết nữa.

Về nguyên tắc, bất kỳ tỷ lệ nào (kể cả theo chiều ngang) đều có thể đạt được trên nhiều công nghệ. Bây giờ rất thường xuyên Chúng ta đang nói vềđể khi tạo dịch vụ bạn không phải trả quá nhiều tiền cho phần cứng. Để làm được điều này, điều quan trọng là phải biết công nghệ nào phù hợp nhất hồ sơ này tải với chi phí tối thiểuốc lắp cáp. Đồng thời, rất thường xuyên, khi họ bắt đầu nghĩ đến việc mở rộng quy mô, họ quên mất khía cạnh tài chính của việc mở rộng quy mô theo chiều ngang. Một số người cho rằng việc chia tỷ lệ theo chiều ngang thực sự là một loại thuốc chữa bách bệnh. Chúng tôi đã tách dữ liệu, phân tán mọi thứ vào các máy chủ riêng biệt - và mọi thứ trở nên bình thường. Tuy nhiên, những người này quên mất chi phí chung - cả về tài chính (mua máy chủ mới) và hoạt động. Khi chúng tôi chia mọi thứ thành các thành phần, sẽ có chi phí liên lạc thành phần phần mềm giữa bọn họ. Nói một cách đại khái thì có nhiều bước nhảy hơn. Hãy nhớ lại một ví dụ đã quen thuộc với bạn. Khi chúng tôi đi đến trang Facebook, JavaScript mạnh mẽ sẽ đi đến máy chủ, máy chủ này sẽ suy nghĩ rất lâu và chỉ sau một thời gian mới bắt đầu cung cấp dữ liệu của bạn cho bạn. Mọi người đều đã thấy một bức tranh tương tự: bạn muốn nhìn vào nó rồi chạy đi uống cà phê, nhưng nó cứ tải mãi, tải mãi. Cần phải lưu trữ dữ liệu “gần hơn” một chút, nhưng Facebook không còn tùy chọn này nữa.

Phân lớp mã

Một số mẹo khác để giúp việc chia tỷ lệ theo chiều ngang dễ dàng hơn. Đề xuất đầu tiên: lập trình sao cho mã của bạn bao gồm các lớp và mỗi lớp chịu trách nhiệm về một quy trình cụ thể trong chuỗi xử lý dữ liệu. Giả sử, nếu bạn đang làm việc với cơ sở dữ liệu thì việc đó phải được thực hiện ở một nơi và không nằm rải rác trên tất cả các tập lệnh. Ví dụ: chúng tôi đang xây dựng một trang người dùng. Tất cả bắt đầu với kernel chạy mô-đun logic nghiệp vụ để xây dựng trang người dùng. Mô-đun này truy vấn lớp lưu trữ dữ liệu cơ bản để biết thông tin về người dùng cụ thể đó. Lớp logic nghiệp vụ không biết dữ liệu ở đâu: dữ liệu đó có được lưu vào bộ nhớ đệm hay không, phân đoạn (sharding là việc phân phối dữ liệu trên các máy chủ lưu trữ dữ liệu khác nhau, điều mà chúng ta sẽ nói đến trong các bài học sau) hay điều gì khác đã được thực hiện với nó không tốt . Mô-đun chỉ yêu cầu thông tin bằng cách gọi hàm thích hợp. Chức năng đọc thông tin người dùng nằm ở lớp lưu trữ dữ liệu. Đổi lại, lớp lưu trữ dữ liệu theo loại yêu cầu sẽ xác định nơi lưu trữ mà người dùng được lưu trữ. Trong bộ nhớ đệm? Trong cơ sở dữ liệu? Trên hệ thống tập tin? Và sau đó gọi hàm tương ứng của lớp bên dưới.

Sơ đồ phân lớp như vậy cung cấp những gì? Nó có thể viết lại, loại bỏ hoặc thêm toàn bộ lớp. Ví dụ: giả sử bạn quyết định thêm bộ nhớ đệm cho người dùng. Thực hiện điều này theo sơ đồ phân lớp rất đơn giản: bạn chỉ cần thêm một địa điểm - lớp lưu trữ dữ liệu. Hoặc bạn thêm phân đoạn và giờ đây người dùng có thể cư trú trong các cơ sở dữ liệu khác nhau. Theo sơ đồ thông thường, bạn sẽ phải tìm hiểu toàn bộ trang web và chèn các kiểm tra thích hợp vào mọi nơi. Trong mạch phân lớp, bạn chỉ cần sửa logic của một lớp, một mô-đun cụ thể.

Sự gắn kết giữa mã và dữ liệu

Nhiệm vụ quan trọng tiếp theo cần được giải quyết để tránh các vấn đề khi mở rộng theo chiều ngang là giảm thiểu sự ghép nối giữa cả mã và dữ liệu. Ví dụ: nếu bạn sử dụng THAM GIA trong các truy vấn SQL của mình, bạn đã có vấn đề tiềm tàng. Bạn có thể thực hiện THAM GIA trong một cơ sở dữ liệu. Nhưng trong khuôn khổ hai cơ sở dữ liệu nằm trên các máy chủ khác nhau, điều này không còn khả thi nữa. Khuyến nghị chung: cố gắng giao tiếp với kho lưu trữ bằng cách sử dụng các truy vấn, bước lặp, bước đơn giản tối thiểu.

Phải làm gì nếu bạn không thể làm gì nếu không THAM GIA? Hãy tự mình thực hiện: thực hiện hai yêu cầu, nhân lên trong PHP - điều đó không có gì sai cả. Ví dụ: hãy xem xét nhiệm vụ cơ bản là xây dựng nguồn cấp dữ liệu bạn bè. Bạn cần nâng cao tất cả bạn bè của người dùng, yêu cầu mọi thứ cho họ những ghi chú cuối cùng, đối với tất cả các bài đăng, hãy thu thập số lượng nhận xét - đây là lúc sự cám dỗ để thực hiện điều này trong một truy vấn (với một số lượng THAM GIA lồng nhau nhất định) đặc biệt lớn. Chỉ cần một yêu cầu và bạn sẽ có được tất cả thông tin bạn cần. Nhưng bạn sẽ làm gì khi có quá nhiều người dùng và hồ sơ và cơ sở dữ liệu không thể đáp ứng được nữa? Theo cách tốt, cần phải chia sẻ người dùng (trải đều trên các máy chủ cơ sở dữ liệu khác nhau). Rõ ràng là trong trường hợp này sẽ không thể thực hiện thao tác THAM GIA được nữa: dữ liệu được chia thành các cơ sở dữ liệu khác nhau. Vì vậy, bạn phải làm mọi thứ bằng tay. Kết luận rất rõ ràng: hãy làm thủ công ngay từ đầu. Đầu tiên hãy truy vấn cơ sở dữ liệu về tất cả bạn bè của người dùng (truy vấn đầu tiên). Sau đó lấy các bài đăng cuối cùng của những người dùng này (truy vấn thứ hai hoặc nhóm truy vấn). Sau đó sắp xếp qua bộ nhớ của bạn và chọn những gì bạn cần. Trên thực tế, bạn đang thực hiện thao tác THAM GIA theo cách thủ công. Có, bạn có thể không làm điều đó hiệu quả như cơ sở dữ liệu. Nhưng bạn không hề bị giới hạn bởi khối lượng cơ sở dữ liệu này trong việc lưu trữ thông tin. Bạn có thể phân chia và phân phối dữ liệu của mình đến các máy chủ khác nhau hoặc thậm chí tới các DBMS khác nhau! Tất cả điều này hoàn toàn không đáng sợ như nó có vẻ. Trong một hệ thống phân lớp được xây dựng đúng cách, hầu hết các yêu cầu này sẽ được lưu vào bộ đệm. Chúng đơn giản và dễ dàng lưu vào bộ đệm - không giống như kết quả của thao tác THAM GIA. Một nhược điểm khác của tùy chọn THAM GIA: khi được người dùng thêm vào lối đi mới bạn cần phải thiết lập lại bộ đệm mẫu của tất cả bạn bè của anh ấy! Và trong tình huống này, vẫn chưa biết điều gì thực sự sẽ hoạt động nhanh hơn.

Bộ nhớ đệm

Công cụ quan trọng tiếp theo chúng ta sẽ tìm hiểu hôm nay là bộ nhớ đệm. Bộ đệm là gì? Bộ đệm là nơi bạn có thể đặt dữ liệu dưới một số khóa mất nhiều thời gian để tính toán. Hãy nhớ một trong những điểm chính: bộ đệm sẽ cung cấp cho bạn dữ liệu bằng cách sử dụng khóa này nhanh hơn việc tính toán lại. Chúng tôi đã nhiều lần gặp phải tình huống không như vậy và mọi người lãng phí thời gian một cách vô nghĩa. Đôi khi cơ sở dữ liệu hoạt động khá nhanh và việc truy cập trực tiếp vào nó sẽ dễ dàng hơn. Thứ hai thời điểm quan trọng: Bộ đệm phải giống nhau cho tất cả các chương trình phụ trợ.

Thứ hai tâm điểm. Bộ đệm là một cách để che đậy vấn đề về hiệu suất hơn là giải quyết nó. Tuy nhiên, tất nhiên, có những tình huống mà việc giải quyết một vấn đề sẽ rất tốn kém. Vì vậy, bạn nói: "Được rồi, tôi sẽ che vết nứt trên tường này bằng thạch cao và chúng ta sẽ nghĩ rằng nó không có ở đó." Đôi khi nó có tác dụng - thực tế là nó có tác dụng rất thường xuyên. Đặc biệt là khi bạn vào bộ đệm và dữ liệu bạn muốn hiển thị đã có sẵn. Một ví dụ cổ điển là quầy tính bạn bè. Đây là bộ đếm trong cơ sở dữ liệu và thay vì xem qua toàn bộ cơ sở dữ liệu để tìm kiếm bạn bè của bạn, việc lưu dữ liệu này vào bộ nhớ đệm sẽ dễ dàng hơn nhiều (và không phải tính toán lại mỗi lần).

Đối với bộ đệm, có một tiêu chí về hiệu quả sử dụng, tức là một chỉ báo cho thấy nó hoạt động - nó được gọi là Tỷ lệ trúng. Đây là tỷ lệ giữa số lượng yêu cầu mà câu trả lời được tìm thấy trong bộ đệm so với Tổng số yêu cầu. Nếu nó ở mức thấp (50-60%), thì bạn sẽ có thêm chi phí sử dụng bộ đệm. Điều này có nghĩa là trên hầu hết mọi trang thứ hai, người dùng, thay vì lấy dữ liệu từ cơ sở dữ liệu, lại đi vào bộ nhớ đệm: phát hiện ra rằng không có dữ liệu nào cho mình ở đó và sau đó truy cập trực tiếp vào cơ sở dữ liệu. Và đây là thêm hai, năm, mười, bốn mươi mili giây.

Làm thế nào để đảm bảo Tỷ lệ trúng tốt? Ở những nơi cơ sở dữ liệu của bạn chậm và ở những nơi dữ liệu có thể được tính toán lại trong thời gian khá dài, bạn cắm Memcache, Redis hoặc một công cụ tương tự sẽ đóng vai trò là bộ đệm nhanh - và điều này bắt đầu cứu bạn. Ít nhất là tạm thời.

Oleg Bunin

Chuyên gia nổi tiếng trong các dự án Highload. Công ty Oleg Bunin Laboratory của ông chuyên tư vấn, phát triển và thử nghiệm các dự án web có tải trọng cao. Hiện tại anh ấy là người tổ chức hội nghị HighLoad++ (www.highload.ru). Đây là hội nghị dành riêng cho các tải trọng lớn, được quy tụ hàng năm tốt nhất trên thế giới chuyên gia phát triển dự án chính. Nhờ hội nghị này, tôi biết tất cả các chuyên gia hàng đầu trong thế giới về hệ thống tải cao.

Konstantin Osipov

Chuyên gia cơ sở dữ liệu người trong một khoảng thời gian dài làm việc tại MySQL, nơi tôi chịu trách nhiệm về khu vực có tải trọng cao. Tốc độ của MySQL phần lớn là do Kostya Osipov. Trong thời gian của tôi anh ấy đã làm việc về khả năng mở rộng của MySQL 5.5. Hiện tại, anh ấy chịu trách nhiệm tại Mail.Ru về cơ sở dữ liệu NoSQL được phân cụm Tarantool, phục vụ 500–600 nghìn truy vấn mỗi giây. Dùng cái này Mã nguồn mở Bất cứ ai cũng có thể thực hiện dự án.

Maxim Lapshin

Các giải pháp tổ chức phát sóng video hiện có trên thế giới khoảnh khắc này, có thể đếm được trên một bàn tay. Max đã phát triển một trong số chúng - Erlyvideo (erlyvideo.org). Cái này ứng dụng máy chủ, liên quan đến việc truyền phát video. Khi tạo ra những công cụ như vậy, cả đống những vấn đề khó khăn nhất Với tốc độ. Maxim cũng có một số kinh nghiệm trong việc mở rộng quy mô các trang web cỡ trung bình (không lớn bằng Mail.Ru). Ở mức trung bình, chúng tôi muốn nói đến những trang web như vậy, số lượt truy cập đạt khoảng 60 triệu mỗi ngày.

Konstantin Mashukov

Nhà phân tích kinh doanh tại công ty của Oleg Bunin. Konstantin đến từ thế giới siêu máy tính, nơi ông đã làm việc trong một thời gian dài về nhiều ứng dụng khoa học khác nhau liên quan đến máy tính số. Là một nhà phân tích kinh doanh, cô tham gia vào tất cả các dự án tư vấn của công ty, có thể là mạng xã hội, cửa hàng trực tuyến lớn hoặc hệ thống thanh toán điện tử.

Vấn đề vô hiệu hóa bộ đệm

Nhưng với việc sử dụng bộ đệm, bạn sẽ gặp phải vấn đề vô hiệu hóa bộ đệm như một phần thưởng. Vấn đề ở đây là gì? Bạn đưa dữ liệu vào bộ đệm và lấy dữ liệu từ bộ đệm nhưng lúc này dữ liệu gốc đã thay đổi. Ví dụ: Mashenka đã thay đổi chú thích bên dưới ảnh của cô ấy và vì lý do nào đó mà bạn đặt một dòng vào bộ đệm thay vì mỗi lần lấy nó từ cơ sở dữ liệu. Kết quả là bạn đang hiển thị dữ liệu cũ - đây là sự cố vô hiệu hóa bộ đệm. TRONG trường hợp chung không có giải pháp nào vì vấn đề này liên quan đến việc sử dụng dữ liệu của ứng dụng doanh nghiệp của bạn. Câu hỏi chính là: khi nào cần cập nhật bộ đệm? Đôi khi thật khó để trả lời. Ví dụ: người dùng đăng lên mạng xã hội bài đăng mới - giả sử tại thời điểm này chúng tôi đang cố gắng loại bỏ tất cả dữ liệu không hợp lệ. Hóa ra bạn cần đặt lại và cập nhật tất cả bộ đệm có liên quan đến bài đăng này. Trong trường hợp xấu nhất, nếu một người tạo một bài đăng, bạn xóa bộ nhớ đệm khỏi nguồn cấp bài đăng của họ, xóa tất cả bộ nhớ đệm khỏi nguồn cấp dữ liệu bạn bè của họ, xóa tất cả bộ nhớ đệm khỏi nguồn cấp dữ liệu của những người có những người trong cộng đồng đó là bạn bè, và như thế. Cuối cùng, bạn đã xóa một nửa bộ nhớ đệm trên hệ thống. Khi Zuckerberg xuất bản một bài đăng cho 11 triệu rưỡi người đăng ký của mình, liệu chúng ta có nên đặt lại bộ nhớ đệm bạn bè của 11 triệu rưỡi người đăng ký này không? Làm thế nào để đối phó với tình trạng này? Không, chúng tôi sẽ làm theo cách khác và cập nhật bộ đệm khi yêu cầu nguồn cấp dữ liệu bạn bè có chứa bài đăng mới này. Hệ thống phát hiện không có bộ đệm, tiến hành tính toán lại. Cách tiếp cận rất đơn giản và vững chắc. Tuy nhiên, cũng có những nhược điểm: nếu bộ đệm của một trang phổ biến được đặt lại, bạn có nguy cơ gặp phải cái gọi là tình trạng chủng tộc, tức là tình huống trong đó chính bộ đệm này sẽ được tính toán đồng thời bởi một số quy trình (một số người dùng đã quyết định truy cập dữ liệu mới). Kết quả là hệ thống của bạn đang tham gia vào một hoạt động khá trống rỗng - tính toán đồng thời lượng dữ liệu giống hệt thứ n.

Một lối thoát là sử dụng nhiều cách tiếp cận cùng một lúc. Bạn không chỉ xóa giá trị lỗi thời khỏi bộ đệm, bạn chỉ đánh dấu nó là lỗi thời và đồng thời xếp hàng tác vụ để tính toán lại giá trị mới. Trong khi công việc xếp hàng đang được xử lý, người dùng sẽ nhận được một giá trị cũ. Điều này được gọi là suy giảm chức năng: bạn cố tình cho rằng một số người dùng sẽ không nhận được dữ liệu mới nhất. Hầu hết các hệ thống có logic kinh doanh được cân nhắc kỹ lưỡng đều có cách tiếp cận tương tự trong kho vũ khí của chúng.

Sự cố khởi động với bộ nhớ đệm không được làm nóng

Một vấn đề khác là bắt đầu với bộ đệm không được làm nóng (nghĩa là chưa được lấp đầy). Tình huống này minh họa rõ ràng rằng bộ đệm không thể giải quyết được vấn đề cơ sở dữ liệu chậm. Giả sử bạn muốn hiển thị cho người dùng top 20 bài viết tốt cho bất kỳ thời kỳ nào. Thông tin này có trong bộ nhớ đệm của bạn nhưng vào thời điểm hệ thống khởi động, bộ nhớ đệm đã bị xóa. Theo đó, tất cả người dùng đều truy cập vào cơ sở dữ liệu, mất khoảng 500 mili giây để xây dựng chỉ mục. Kết quả là mọi thứ bắt đầu hoạt động chậm và bạn đã tự gây ra DoS (Từ chối dịch vụ). Trang web không hoạt động. Do đó, kết luận: không thực hiện lưu vào bộ đệm cho đến khi bạn giải quyết được các vấn đề khác. Làm cho cơ sở dữ liệu hoạt động nhanh chóng và bạn sẽ không cần phải bận tâm đến bộ nhớ đệm. Tuy nhiên, ngay cả vấn đề bắt đầu với bộ đệm trống cũng có giải pháp:

  1. Sử dụng bộ nhớ đệm với tính năng ghi đĩa (chúng tôi mất tốc độ);
  2. Điền thủ công vào bộ đệm trước khi bắt đầu (người dùng chờ đợi và phẫn nộ);
  3. Cho người dùng vào trang web theo đợt (người dùng vẫn chờ đợi và phẫn nộ).

Như bạn có thể thấy, bất kỳ phương pháp nào cũng xấu, vì vậy chúng tôi sẽ chỉ lặp lại: cố gắng làm cho hệ thống của bạn hoạt động mà không cần bộ nhớ đệm.

Khả năng mở rộng - khả năng của một thiết bị để tăng
khả năng
bằng cách tăng số lượng khối chức năng,
biểu diễn một mình và
những nhiệm vụ giống nhau.
Thuật ngữ.ru

Thông thường mọi người bắt đầu nghĩ đến việc mở rộng quy mô khi một
máy chủ không thể đối phó với công việc được giao cho nó. Chính xác thì anh ấy không ở cùng với cái gì?
đối phó? Hoạt động của bất kỳ máy chủ web nào nhìn chungđi đến những điều cơ bản
Công việc của máy tính là xử lý dữ liệu. Phản hồi yêu cầu HTTP (hoặc bất kỳ yêu cầu nào khác)
liên quan đến việc thực hiện một số thao tác trên một số dữ liệu. Tương ứng,
chúng tôi có hai thực thể chính - dữ liệu (được đặc trưng bởi khối lượng của nó) và
tính toán (đặc trưng bởi độ phức tạp). Máy chủ có thể không có khả năng đối phó với
hoạt động do lượng dữ liệu lớn (nó có thể không phù hợp về mặt vật lý trên
máy chủ) hoặc do tải tính toán nặng. Cuộc nói chuyện ở đây là
tất nhiên, về tổng tải - độ phức tạp của việc xử lý một yêu cầu có thể là
tuy nhỏ nhưng số lượng lớn có thể làm quá tải máy chủ.

Chúng ta sẽ chủ yếu nói về việc mở rộng quy mô bằng một ví dụ
dự án web đang phát triển điển hình, nhưng các nguyên tắc được mô tả ở đây cũng phù hợp với
các lĩnh vực ứng dụng khác. Đầu tiên chúng ta sẽ xem xét kiến ​​trúc dự án và đơn giản
sự phân phối của nó các thành phần tới một số máy chủ và sau đó chúng ta sẽ nói về
tính toán và mở rộng quy mô dữ liệu.

Kiến trúc trang web điển hình

Vòng đời của một trang web điển hình bắt đầu với một kiến ​​trúc rất đơn giản
- đây là một máy chủ web (thường là Apache đóng vai trò của nó),
xử lý tất cả công việc phục vụ các yêu cầu HTTP,
nhận được từ du khách. Anh ta cung cấp cho khách hàng cái gọi là “số liệu thống kê”, sau đó
có những tập tin nằm trên đĩa máy chủ không cần xử lý: ảnh (gif,
jpg, png), biểu định kiểu (css), tập lệnh máy khách (js, swf). Cùng một máy chủ
trả lời các truy vấn yêu cầu tính toán - thường tạo thành
các trang html, mặc dù đôi khi hình ảnh và các tài liệu khác được tạo ra một cách nhanh chóng.
Thông thường, phản hồi cho những yêu cầu như vậy được tạo ra bởi các tập lệnh viết bằng PHP,
perl hoặc các ngôn ngữ khác.

Nhược điểm của sơ đồ làm việc đơn giản như vậy là khác biệt
bản chất của các yêu cầu (tải tệp lên từ đĩa và công việc tính toán kịch bản)
được xử lý bởi cùng một máy chủ web. Các truy vấn tính toán yêu cầu
giữ nhiều thông tin trong bộ nhớ máy chủ (trình thông dịch ngôn ngữ kịch bản,
chính các tập lệnh, dữ liệu chúng làm việc) và có thể chiếm rất nhiều
tài nguyên tính toán. Ngược lại, việc phát hành dữ liệu tĩnh đòi hỏi ít tài nguyên
bộ xử lý, nhưng có thể chiếm thời gian dài, nếu khách hàng có mức thấp
tốc độ truyền thông. Tổ chức nội bộ máy chủ Apache giả định rằng mọi
kết nối được xử lý bởi một quá trình riêng biệt. Điều này thuận tiện cho việc chạy các tập lệnh,
tuy nhiên không tối ưu để xử lý truy vấn đơn giản. Hóa ra nặng đến thế (từ
tập lệnh và dữ liệu khác) Các quy trình của Apache dành nhiều thời gian chờ đợi (đầu tiên khi nhận được
yêu cầu, sau đó gửi phản hồi), gây lãng phí bộ nhớ máy chủ.

Giải pháp cho vấn đề này là phân phối công việc xử lý
yêu cầu giữa hai các chương trình khác nhau- I E. phân chia thành frontend và
phụ trợ Một máy chủ giao diện người dùng nhẹ thực hiện các nhiệm vụ cung cấp nội dung tĩnh và phần còn lại
các yêu cầu được chuyển hướng (proxy) đến phần phụ trợ, nơi việc hình thành được thực hiện
trang. Việc chờ đợi các máy khách chậm cũng được giao diện người dùng xử lý và nếu nó sử dụng
ghép kênh (khi một tiến trình phục vụ nhiều máy khách - vì vậy
hoạt động, chẳng hạn như nginx hoặc lighttpd), thì thực tế việc chờ đợi là không có gì
chi phí.

Trong số các thành phần khác của trang web, cơ sở dữ liệu cần được lưu ý, trong
thường lưu trữ dữ liệu hệ thống chính - phổ biến nhất ở đây là
DBMS MySQL và PostgreSQL miễn phí. Dung lượng lưu trữ thường được phân bổ riêng
tập tin nhị phân, chứa hình ảnh (ví dụ: hình minh họa cho bài viết
trang web, hình đại diện và ảnh người dùng) hoặc các tệp khác.

Như vậy, chúng ta đã nhận được một sơ đồ kiến ​​trúc bao gồm
một số thành phần.

Thông thường, khi bắt đầu vòng đời của một trang web, tất cả các thành phần của kiến ​​trúc
nằm trên cùng một máy chủ. Nếu nó ngừng đối phó với tải, thì
Có một giải pháp đơn giản - di chuyển những phần dễ tách nhất sang phần khác
máy chủ. Cách dễ nhất để bắt đầu với cơ sở dữ liệu là di chuyển nó đến một máy chủ riêng biệt và
thay đổi chi tiết truy cập trong tập lệnh. Nhân tiện, tại thời điểm này chúng ta đang phải đối mặt với
tầm quan trọng của kiến ​​trúc phù hợp Mã chương trình. Nếu làm việc với cơ sở dữ liệu
nộp cho mô-đun riêng biệt, chung cho toàn bộ trang web - sau đó sửa các tham số
kết nối sẽ dễ dàng.

Các cách để phân tách thêm các thành phần cũng rõ ràng - ví dụ: bạn có thể di chuyển giao diện người dùng sang một máy chủ riêng. Nhưng thông thường lối vào
đòi hỏi ít tài nguyên hệ thống và ở giai đoạn này việc loại bỏ nó sẽ không mang lại kết quả đáng kể
tăng năng suất. Thông thường, trang web bị giới hạn bởi hiệu suất.
tập lệnh - việc tạo phản hồi (trang html) mất quá nhiều thời gian.
Đó là lý do tại sao bước tiếp theo thường mở rộng quy mô máy chủ phụ trợ.

Tính toán phân phối

Một tình huống điển hình cho một trang web đang phát triển - cơ sở dữ liệu đã sẵn sàng
được chuyển sang một máy riêng, việc phân chia thành frontend và backend hoàn tất,
tuy nhiên, lưu lượng truy cập tiếp tục tăng và phần phụ trợ không có thời gian để xử lý
yêu cầu. Điều này có nghĩa là chúng ta cần phân phối các phép tính trên một số
may chủ. Việc này rất dễ thực hiện - chỉ cần mua máy chủ thứ hai và cài đặt nó trên
Nó chứa các chương trình và tập lệnh cần thiết để phần phụ trợ hoạt động.
Sau này, bạn cần đảm bảo rằng yêu cầu của người dùng được phân phối
(cân bằng) giữa các máy chủ nhận được. VỀ theo những cách khác nhau cân bằng
sẽ được thảo luận bên dưới, nhưng hiện tại chúng tôi lưu ý rằng việc này thường được thực hiện bởi giao diện người dùng,
được cấu hình sao cho nó phân bổ đồng đều các yêu cầu giữa
may chủ.

Điều quan trọng là tất cả các máy chủ phụ trợ đều có khả năng hoạt động chính xác
đáp ứng các yêu cầu. Điều này thường yêu cầu mỗi người trong số họ phải làm việc với
cùng một bộ dữ liệu cập nhật. Nếu chúng ta lưu trữ tất cả thông tin trong một
cơ sở dữ liệu thì chính DBMS sẽ cung cấp chia sẻ và tính nhất quán của dữ liệu.
Nếu một số dữ liệu được lưu trữ cục bộ trên máy chủ (ví dụ: phiên php
client), thì bạn nên nghĩ đến việc chuyển chúng sang lưu trữ chia sẻ, hoặc về hơn thế nữa
thuật toán phân phối yêu cầu phức tạp.

Không chỉ công việc có thể được phân phối trên nhiều máy chủ
các tập lệnh mà còn cả các phép tính được thực hiện bởi cơ sở dữ liệu. Nếu DBMS thực hiện nhiều
các truy vấn phức tạp, chiếm nhiều thời gian của CPU máy chủ, bạn có thể tạo một số truy vấn
bản sao của cơ sở dữ liệu tới máy chủ khác nhau. Điều này đặt ra vấn đề đồng bộ hóa
dữ liệu khi thay đổi và một số cách tiếp cận được áp dụng ở đây.

  • Đồng bộ hóa ở cấp độ ứng dụng. Trong trường hợp này của chúng tôi
    các tập lệnh viết các thay đổi một cách độc lập cho tất cả các bản sao của cơ sở dữ liệu (và chúng mang theo
    chịu trách nhiệm về tính chính xác của dữ liệu). Không phải sự lựa chọn tốt nhất bởi vì anh ấy
    đòi hỏi sự cẩn thận trong việc thực hiện và có khả năng chịu lỗi cao.
  • Nhân rộng- nghĩa là, sao chép tự động
    những thay đổi được thực hiện trên một máy chủ sẽ ảnh hưởng đến tất cả các máy chủ khác. Thông thường khi
    Khi sử dụng bản sao, các thay đổi luôn được ghi vào cùng một máy chủ - nó được gọi là máy chủ chính và các bản sao còn lại được gọi là máy chủ phụ. Hầu hết các DBMS đều có
    tích hợp hoặc quỹ bên ngoàiđể tổ chức sao chép. Phân biệt
    sao chép đồng bộ - trong trường hợp này, yêu cầu thay đổi dữ liệu sẽ chờ
    cho đến khi dữ liệu được sao chép sang tất cả các máy chủ và chỉ khi đó dữ liệu mới hoàn tất thành công - và không đồng bộ - trong trường hợp này, các thay đổi mới được sao chép sang máy chủ phụ từ
    chậm trễ, nhưng yêu cầu ghi hoàn thành nhanh hơn.
  • Đa chủ nhân rộng. Cách tiếp cận này tương tự
    cái trước, nhưng ở đây chúng ta có thể thay đổi dữ liệu mà không cần truy cập
    một máy chủ cụ thể nhưng tới bất kỳ bản sao nào của cơ sở dữ liệu. Đồng thời, những thay đổi
    đồng bộ hoặc không đồng bộ sẽ được chuyển sang các bản sao khác. Đôi khi sơ đồ này được gọi
    thuật ngữ "cụm cơ sở dữ liệu".

Khả thi các biến thể khác nhau phân phối hệ thống giữa các máy chủ.
Ví dụ: chúng tôi có thể có một máy chủ cơ sở dữ liệu và một số chương trình phụ trợ (rất
lược đồ điển hình) hoặc ngược lại - một phụ trợ và một số cơ sở dữ liệu. Điều gì sẽ xảy ra nếu chúng ta mở rộng quy mô
cả máy chủ phụ trợ và cơ sở dữ liệu, thì bạn có thể kết hợp phần phụ trợ và bản sao của cơ sở dữ liệu trên
một chiếc xe hơi. Trong mọi trường hợp, ngay khi chúng tôi có vài bản sao
bất kỳ máy chủ nào, câu hỏi đặt ra là làm thế nào để phân phối chính xác giữa chúng
trọng tải.

Phương pháp cân bằng

Chúng ta hãy tạo một số máy chủ (cho bất kỳ mục đích nào - http, cơ sở dữ liệu, v.v.), mỗi máy chủ có thể xử lý yêu cầu. Trước
chúng ta phải đối mặt với nhiệm vụ làm thế nào để phân phối công việc giữa họ, làm thế nào để tìm ra cái nào
máy chủ gửi yêu cầu? Có hai cách chính để phân phối yêu cầu.

  • Bộ cân bằng. Trong trường hợp này, client gửi yêu cầu tới một
    một máy chủ cố định mà anh ta biết và nó đã chuyển hướng yêu cầu đến một trong những
    các máy chủ làm việc. Ví dụ điển hình- một trang web có một giao diện người dùng và một số giao diện người dùng
    máy chủ phụ trợ mà các yêu cầu được ủy quyền. Tuy nhiên, “khách hàng” có thể
    ở bên trong hệ thống của chúng tôi - ví dụ: một tập lệnh có thể gửi yêu cầu tới
    đến máy chủ proxy cơ sở dữ liệu sẽ chuyển yêu cầu đến một trong các máy chủ DBMS.
    Bản thân nút cân bằng có thể hoạt động cả trên một máy chủ riêng biệt và trên một máy chủ
    từ các máy chủ đang hoạt động.

    Ưu điểm của phương pháp này là
    mà khách hàng không cần biết gì về cơ cấu nội bộ hệ thống - về số lượng
    máy chủ, về địa chỉ và tính năng của chúng - chỉ
    cân bằng. Tuy nhiên, nhược điểm là bộ cân bằng là một thiết bị duy nhất.
    điểm lỗi của hệ thống - nếu nó bị lỗi, toàn bộ hệ thống sẽ bị hỏng.
    không hoạt động. Ngoài ra, khi tải nặng, bộ cân bằng có thể dừng lại
    đối phó với công việc của họ, vì vậy cách tiếp cận này không phải lúc nào cũng có thể áp dụng được.

  • Cân bằng phía khách hàng. Nếu chúng ta muốn tránh
    tồn tại một điểm lỗi duy nhất Lựa chọn thay thế- ủy thác lựa chọn máy chủ
    cho chính khách hàng. Trong trường hợp này, khách hàng phải biết về cấu trúc bên trong của chúng tôi.
    để có thể chọn chính xác máy chủ nào cần liên hệ.
    Một lợi thế chắc chắn là không có điểm thất bại - nếu một trong
    máy chủ mà khách hàng sẽ có thể liên lạc với người khác. Tuy nhiên, cái giá của việc này
    logic máy khách phức tạp hơn và tính linh hoạt cân bằng kém hơn.


Tất nhiên, cũng có sự kết hợp của những cách tiếp cận này. Ví dụ,
như là phương pháp đã biết cân bằng tải, giống như cân bằng DNS, dựa trên
rằng khi xác định địa chỉ IP của một trang web, khách hàng sẽ được cung cấp
địa chỉ của một trong nhiều máy chủ giống hệt nhau. Vì vậy, DNS hoạt động như một
vai trò của nút cân bằng mà từ đó khách hàng nhận được “phân phối”. Tuy nhiên
chính cấu trúc của máy chủ DNS hàm ý rằng không có điểm lỗi do
trùng lặp - nghĩa là những ưu điểm của hai phương pháp được kết hợp. Tất nhiên, cái này
Phương pháp cân bằng cũng có những nhược điểm - ví dụ, một hệ thống như vậy khó có thể hoạt động linh hoạt.
xây dựng lại.

Làm việc với một trang web thường không bị giới hạn ở một yêu cầu.
Vì vậy, khi thiết kế, điều quan trọng là phải hiểu liệu các truy vấn tuần tự có thể
máy khách được xử lý chính xác bởi các máy chủ khác nhau, hoặc máy khách phải
được gắn với một máy chủ trong khi làm việc với trang web. Điều này đặc biệt quan trọng nếu
trang web lưu trữ thông tin tạm thời về phiên của người dùng (trong trường hợp này
Trong trường hợp này, cũng có thể phân phối miễn phí - nhưng sau đó cần phải lưu trữ
phiên (bộ nhớ chung cho tất cả các máy chủ). “Ràng buộc” khách truy cập
bạn có thể chỉ định một máy chủ cụ thể theo địa chỉ IP của nó (tuy nhiên, địa chỉ này có thể thay đổi),
hoặc bằng cookie (trong đó mã định danh máy chủ được ghi trước) hoặc thậm chí
chỉ đơn giản bằng cách chuyển hướng nó đến tên miền mong muốn.

Mặt khác, các máy chủ điện toán có thể không có quyền bình đẳng.
Trong một số trường hợp, sẽ thuận lợi hơn nếu làm ngược lại, phân bổ một máy chủ riêng cho
xử lý các yêu cầu thuộc một loại - và nhận được sự phân chia theo chiều dọc
chức năng. Sau đó máy khách hoặc nút cân bằng sẽ chọn máy chủ trong
tùy thuộc vào loại yêu cầu nhận được. Phương pháp này cho phép chúng ta tách
những yêu cầu quan trọng (hoặc ngược lại, không quan trọng nhưng khó khăn) từ người khác.

Phân phối dữ liệu

Chúng ta đã học cách phân phối các phép tính, vì vậy một lượng lớn
việc tham dự không phải là vấn đề đối với chúng tôi. Tuy nhiên, khối lượng dữ liệu tiếp tục tăng lên,
việc lưu trữ và xử lý chúng ngày càng trở nên khó khăn - điều đó có nghĩa là đã đến lúc xây dựng
lưu trữ dữ liệu phân tán. Trong trường hợp này, chúng ta sẽ không còn một hoặc
một số máy chủ chứa bản sao hoàn chỉnh của cơ sở dữ liệu. Thay vào đó, dữ liệu
sẽ được phân phối trên các máy chủ khác nhau. Những kế hoạch phân phối nào có thể thực hiện được?

  • Phân phối theo chiều dọc(phân vùng theo chiều dọc) - trong trường hợp đơn giản nhất
    cấu thành một phán quyết bảng riêng biệt cơ sở dữ liệu đến một máy chủ khác. Tại
    Trong trường hợp này, chúng tôi sẽ cần thay đổi tập lệnh để truy cập các máy chủ khác nhau cho
    dữ liệu khác nhau. Trong giới hạn, chúng ta có thể lưu trữ từng bảng trên một máy chủ riêng
    (mặc dù trong thực tế điều này khó có thể mang lại lợi ích). Rõ ràng, với điều này
    phân phối, chúng tôi mất khả năng thực hiện các truy vấn SQL kết hợp dữ liệu từ
    hai bảng nằm trên các máy chủ khác nhau. Nếu cần thiết, bạn có thể triển khai
    hợp nhất logic trong ứng dụng, nhưng nó sẽ không hiệu quả như trong DBMS.
    Vì vậy, khi phân vùng cơ sở dữ liệu cần phân tích mối quan hệ giữa các bảng,
    để phân phối các bảng độc lập nhất có thể.

    Trường hợp phức tạp hơn
    Phân phối cơ sở dọc là sự phân rã của một bảng khi một phần
    một số cột của nó kết thúc trên một máy chủ và một số cột kết thúc trên một máy chủ khác. Kỹ thuật này
    ít phổ biến hơn, nhưng có thể được sử dụng, ví dụ, để tách các phần nhỏ
    và dữ liệu được cập nhật thường xuyên từ một khối lượng lớn dữ liệu hiếm khi được sử dụng.

  • Phân bố theo chiều ngang(phân vùng ngang) - bao gồm
    phân phối dữ liệu từ một bảng trên nhiều máy chủ. Trên thực tế, trên
    mỗi máy chủ tạo một bảng có cùng cấu trúc và lưu trữ
    một phần dữ liệu nhất định. Bạn có thể phân phối dữ liệu trên các máy chủ theo nhiều cách khác nhau
    tiêu chí: theo phạm vi (bản ghi có id< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
    A, phần còn lại - đến máy chủ B) hoặc theo giá trị băm của một trường nhất định
    Hồ sơ. Phân vùng dữ liệu theo chiều ngang cho phép bạn lưu trữ không giới hạn
    tuy nhiên số lượng hồ sơ làm phức tạp việc lựa chọn. Cách lựa chọn hiệu quả nhất
    chỉ ghi lại khi biết chúng được lưu trữ trên máy chủ nào.

Để lựa chọn sơ đồ đúng phân phối dữ liệu là cần thiết
phân tích cẩn thận cấu trúc của cơ sở dữ liệu. Bảng hiện có(và có lẽ,
trường riêng lẻ) có thể được phân loại theo tần suất truy cập vào hồ sơ, theo tần suất
cập nhật và các mối quan hệ (nhu cầu thực hiện các lựa chọn từ một số
những cái bàn).

Như đã đề cập ở trên, ngoài cơ sở dữ liệu, một trang web thường cần
lưu trữ cho các tập tin nhị phân. Hệ thống phân phối lưu trữ tập tin
(Thực ra, hệ thống tập tin) có thể được chia thành hai lớp.

  • Đang làm việc ở cấp hệ điều hành . Đồng thời đối với
    các ứng dụng làm việc với các tập tin trong hệ thống như vậy không khác gì công việc thường xuyên Với
    các tập tin. Việc trao đổi thông tin giữa các máy chủ được xử lý bởi hệ điều hành.
    Ví dụ về các hệ thống tập tin như vậy bao gồm hệ thống tập tin được biết đến từ lâu
    Họ NFS hoặc ít được biết đến hơn, nhưng nhiều hơn hệ thống hiện đại Nước bóng.
  • Đã thực hiện ở cấp độ ứng dụng phân phối
    kho lưu trữ ngụ ý rằng công việc trao đổi thông tin được thực hiện bởi chính nó
    ứng dụng. Thông thường, các chức năng làm việc với bộ nhớ được đặt trong
    thư viện riêng biệt. Một trong những ví dụ nổi bật về việc lưu trữ như vậy là MogileFS, được phát triển bởi
    bởi những người tạo ra LiveJournal. Một ví dụ phổ biến khác là sử dụng
    Giao thức WebDAV và bộ lưu trữ hỗ trợ nó.

Cần lưu ý rằng việc phân phối dữ liệu không chỉ quyết định
vấn đề về lưu trữ, nhưng cũng một phần là vấn đề phân bổ tải - trên mỗi
máy chủ trở thành ít mục hơn và do đó chúng được xử lý nhanh hơn.
Sự kết hợp của các phương pháp phân phối tính toán và dữ liệu giúp có thể xây dựng
kiến trúc có khả năng mở rộng không giới hạn, có khả năng làm việc với
bất kỳ lượng dữ liệu và bất kỳ tải nào.

kết luận

Để tóm tắt những gì đã được nói, chúng ta hãy đưa ra kết luận dưới dạng những luận văn ngắn gọn.

  • Hai thách thức mở rộng chính (và có liên quan) là phân phối điện toán và phân phối dữ liệu
  • Kiến trúc trang web điển hình liên quan đến việc phân chia vai trò và
    bao gồm frontend, backend, cơ sở dữ liệu và đôi khi là lưu trữ tệp
  • Tại khối lượng nhỏ dữ liệu và tải nặngáp dụng
    phản chiếu cơ sở dữ liệu - sao chép đồng bộ hoặc không đồng bộ
  • Đối với lượng dữ liệu lớn cần phải phân tán cơ sở dữ liệu - chia nhỏ
    nó theo chiều dọc hoặc chiều ngang
  • Các tệp nhị phân được lưu trữ trên các hệ thống tệp phân tán
    (được triển khai ở cấp hệ điều hành hoặc trong ứng dụng)
  • Cân bằng (phân phối yêu cầu) có thể thống nhất hoặc
    chia theo chức năng; với nút cân bằng hoặc ở phía máy khách
  • Sự kết hợp đúng đắn của các phương pháp sẽ cho phép bạn chịu được mọi tải trọng;)

Liên kết

Bạn có thể tiếp tục nghiên cứu chủ đề này trên các trang và blog tiếng Anh thú vị.

ALEXANDER KALENDAREV, RBC Media, lập trình viên, [email được bảo vệ]


Vấn đề và giải pháp

Sớm hay muộn, một dự án web hoặc di động phổ biến có phía máy chủ sẽ gặp phải vấn đề về hiệu suất. Một giải pháp là mở rộng quy mô cơ sở dữ liệu theo chiều ngang. Chúng ta nói về cạm bẫy và về những cách có thể bỏ qua chúng

Mỗi dự án đang phát triển đều phải đối mặt với thách thức về năng suất. Do đó, nếu bạn cho rằng dự án của mình đầy tham vọng và sẽ sớm chinh phục cả thế giới, thì bạn nên đưa khả năng mở rộng quy mô ở cấp độ phát triển kiến ​​​​trúc ban đầu.

Hãy làm rõ thuật ngữ:

  • Hiệu suất– khả năng của ứng dụng có thể đáp ứng các yêu cầu như thời gian tối đa phản ứng, thông lượng.
  • Năng lực thông qua)– khả năng tối đa của một ứng dụng để vượt qua một số lượng yêu cầu nhất định trên một đơn vị thời gian hoặc giữ một số phiên người dùng nhất định.
  • Khả năng mở rộng là một đặc điểm của một ứng dụng cho thấy khả năng duy trì hiệu suất khi nó tăng lên băng thông. Đổi lại, mở rộng quy mô là quá trình đảm bảo sự phát triển của hệ thống. Tỷ lệ có thể theo chiều dọc hoặc chiều ngang.
  • Chia tỷ lệ dọc– đây là sự gia tăng năng suất do tăng sức mạnh của phần cứng, dung lượng RAM, v.v. Sớm hay muộn, tỷ lệ dọc sẽ đạt đến giới hạn trên.
  • Chia tỷ lệ theo chiều ngang là tăng năng suất bằng cách chia dữ liệu trên nhiều máy chủ.

Tách dữ liệu chức năng

Có một số tùy chọn để chia tỷ lệ theo chiều ngang. Ví dụ: nó thường được sử dụng để phân tách dữ liệu dựa trên cách sử dụng chức năng. Ví dụ: dữ liệu cho album ảnh được chứa trong một nhóm máy chủ, dữ liệu hồ sơ người dùng được đặt trong một nhóm khác và thư từ của người dùng được đặt trong một nhóm thứ ba. Trong bộ lễ phục. Hình 1 thể hiện sơ đồ chia tỷ lệ theo chiều ngang theo phân bổ chức năng.

Chia tỷ lệ bằng cách sử dụng bản sao

Cách dễ nhất để mở rộng quy mô, thường được sử dụng cho các dự án vừa và nhỏ, là sử dụng tính năng nhân rộng. Sao chép là một cơ chế để đồng bộ hóa nhiều bản sao của một đối tượng và bảng cơ sở dữ liệu (xem Hình 2). Sao chép chính-phụ là sự đồng bộ hóa dữ liệu từ máy chủ chính đến máy chủ nô lệ.

Vì hầu hết các trang web và dự án di động Có nhiều thao tác đọc hơn thao tác ghi, sau đó chúng ta có thể thực hiện thao tác ghi trên một máy chủ chính và đọc dữ liệu từ nhiều máy chủ phụ. Bản sao phải được cấu hình giữa máy chủ chính và phụ.

Nhiều cơ sở dữ liệu có tính năng sao chép tích hợp hoặc như người ta nói, một “giải pháp sẵn có”. Ví dụ: việc sao chép PostgreSQL có thể được thực hiện bằng các tiện ích sau:

  • Slony-I – sao chép không đồng bộ (chính sang nhiều nô lệ);
  • pgpool-I/II – sao chép đa chủ đồng bộ;
  • PGcluster – sao chép đa chủ đồng bộ;
  • Bucardo;
  • London;
  • RubyRep.
  • bắt đầu từ phiên bản 9.0, tính năng sao chép phát trực tuyến được tích hợp sẵn.

Khi nhân rộng bằng cách sử dụng bản sao, bạn phải sử dụng kết nối khác nhau: một với máy chủ chính, chỉ để ghi hoặc cập nhật, và thứ hai, chỉ với máy chủ phụ, trực tiếp để đọc. Hơn nữa, nếu chúng ta sử dụng một số máy chủ nô lệ thì chiến lược lựa chọn có thể là ngẫu nhiên hoặc một máy chủ cơ sở dữ liệu cụ thể được gán cho một máy chủ web cụ thể.

Đọc toàn bộ bài viết trên tạp chí " Quản trị hệ thống", Số 10 cho năm 2014 ở trang 54-62.

Phiên bản PDF số đã cho có thể được mua trong cửa hàng của chúng tôi.


Liên hệ với

Chia tỷ lệ dọc— mở rộng quy mô — tăng số lượng tài nguyên có sẵn cho phần mềm bằng cách tăng sức mạnh sử dụng từ máy chủ.

— mở rộng quy mô — tăng số lượng nút được kết hợp thành một cụm máy chủ khi thiếu CPU, bộ nhớ hoặc dung lượng ổ đĩa.

Cả hai đều là giải pháp cơ sở hạ tầng Những tình huống khác nhau cần thiết khi một dự án web phát triển.

Chia tỷ lệ dọc và ngang, chia tỷ lệ cho web

Ví dụ, hãy xem xét các máy chủ cơ sở dữ liệu. Vì ứng dụng lớnĐây luôn là thành phần được tải nhiều nhất của hệ thống.

Khả năng mở rộng quy mô cho các máy chủ cơ sở dữ liệu được xác định bởi giải pháp phần mềm: thông thường đây là các cơ sở dữ liệu quan hệ (MySQL, Postgresql) hoặc NoSQL(, Cassandra, v.v.).

Chia tỷ lệ theo chiều ngang cho các máy chủ cơ sở dữ liệu chịu tải nặng rẻ hơn nhiều

Một dự án web thường được bắt đầu trên một máy chủ, tài nguyên của nó sẽ cạn kiệt khi nó phát triển. Trong tình huống như vậy, có 2 lựa chọn:

  • di chuyển trang web đến một máy chủ mạnh hơn
  • thêm một máy chủ năng lượng thấp khác và kết hợp các máy thành một cụm

MySQL là RDBMS phổ biến nhất và giống như bất kỳ RDBMS nào trong số đó, yêu cầu nhiều tài nguyên máy chủ để chạy dưới tải. Có thể mở rộng quy mô chủ yếu lên trên. Có sharding (yêu cầu thay đổi mã để định cấu hình) và sharding, có thể khó hỗ trợ.

Chia tỷ lệ dọc

NoSQL có thể mở rộng quy mô một cách dễ dàng và tùy chọn thứ hai, chẳng hạn như MongoDB, sẽ mang lại nhiều lợi nhuận hơn về mặt tài chính và sẽ không yêu cầu cài đặt cũng như hỗ trợ tốn nhiều công sức cho giải pháp thu được. Sharding được thực hiện tự động.

Vì vậy, với MySQL, bạn sẽ cần một máy chủ có số lượng CPU và RAM lớn; những máy chủ như vậy có chi phí đáng kể.

Chia tỷ lệ theo chiều ngang
Với MongoDB bạn có thể thêm một cái nữa máy chủ trung bình và giải pháp thu được sẽ hoạt động ổn định, mang lại khả năng chịu lỗi bổ sung.


Thu nhỏ quy mô hoặc là một giai đoạn tự nhiên của sự phát triển cơ sở hạ tầng. Bất kỳ máy chủ nào cũng có những hạn chế và khi đạt đến giới hạn đó hoặc khi chi phí của một máy chủ mạnh hơn trở nên cao một cách vô lý, các máy mới sẽ được thêm vào. Tải trọng được phân phối giữa chúng. Nó cũng cung cấp khả năng chịu lỗi.

Bạn nên bắt đầu thêm các máy chủ cỡ trung bình và thiết lập các cụm khi khả năng tăng tài nguyên của một máy đã cạn kiệt hoặc khi việc mua một máy chủ mạnh hơn hóa ra không mang lại lợi nhuận.

Ví dụ trên với cơ sở dữ liệu quan hệ và NoSQL là tình huống xảy ra thường xuyên nhất. Các máy chủ frontend và backend cũng có khả năng mở rộng.

Đọc về bộ cân bằng

|

Số lượng khách truy cập trang web không ngừng tăng lên luôn là một thành tựu lớn đối với các nhà phát triển và quản trị viên. Tất nhiên, ngoại trừ những tình huống khi lưu lượng truy cập tăng cao đến mức làm hỏng máy chủ web hoặc phần mềm khác. Việc gián đoạn trang web liên tục luôn gây tốn kém cho công ty.

Tuy nhiên, điều này có thể được sửa chữa. Và nếu bây giờ bạn đang nghĩ đến việc mở rộng quy mô thì bạn đang đi đúng hướng.

Tóm lại, khả năng mở rộng là khả năng hệ thống xử lý một lượng lớn lưu lượng truy cập và thích ứng với sự tăng trưởng của nó trong khi vẫn duy trì UX mong muốn. Có hai phương pháp chia tỷ lệ:

  • Dọc (còn gọi là mở rộng quy mô): tăng tài nguyên hệ thống, chẳng hạn như thêm bộ nhớ và khả năng tính toán. Phương pháp này cho phép bạn giải quyết nhanh chóng các vấn đề khi xử lý lưu lượng truy cập, nhưng tài nguyên của nó có thể nhanh chóng cạn kiệt.
  • Ngang (hoặc thu nhỏ): thêm máy chủ vào cụm. Chúng ta hãy xem xét phương pháp này chi tiết hơn.

Chia tỷ lệ theo chiều ngang là gì?

Nói một cách đơn giản, cụm là một nhóm máy chủ. Bộ cân bằng tải là một máy chủ phân phối khối lượng công việc giữa các máy chủ trong một cụm. Bất cứ lúc nào, bạn có thể thêm máy chủ web vào cụm hiện có để xử lý nhiều lưu lượng truy cập hơn. Đây là bản chất của việc chia tỷ lệ theo chiều ngang.

Bộ cân bằng tải chỉ chịu trách nhiệm quyết định máy chủ nào trong cụm sẽ xử lý yêu cầu nhận được. Về cơ bản, nó hoạt động như một proxy ngược.

Chia tỷ lệ theo chiều ngang chắc chắn là nhiều hơn phương pháp đáng tin cậy tăng hiệu suất ứng dụng, nhưng khó định cấu hình hơn so với chia tỷ lệ dọc. Nhiệm vụ chính và khó khăn nhất trong trường hợp này là liên tục cập nhật và đồng bộ hóa tất cả các nút ứng dụng. Giả sử người dùng A gửi yêu cầu đến mydomain.com, sau đó bộ cân bằng sẽ chuyển yêu cầu đến máy chủ 1. Sau đó, yêu cầu của người dùng B sẽ được máy chủ 2 xử lý.

Điều gì xảy ra nếu người dùng A thực hiện các thay đổi đối với ứng dụng (ví dụ: tải tệp lên hoặc cập nhật nội dung của cơ sở dữ liệu)? Làm thế nào sự thay đổi này có thể được truyền đến các máy chủ còn lại trong cụm?

Câu trả lời cho những câu hỏi này và những câu hỏi khác có thể được tìm thấy trong bài viết này.

Tách máy chủ

Việc chuẩn bị hệ thống để mở rộng quy mô đòi hỏi phải tách các máy chủ; điều rất quan trọng là các máy chủ có ít tài nguyên hơn sẽ có ít trách nhiệm hơn các máy chủ lớn hơn. Ngoài ra, việc chia ứng dụng thành các “phần” này sẽ cho phép bạn nhanh chóng xác định các yếu tố quan trọng của nó.

Giả sử bạn có một ứng dụng PHP cho phép bạn xác thực và tải ảnh lên. Ứng dụng này dựa trên ngăn xếp LAMP. Ảnh được lưu trên đĩa và các liên kết đến chúng được lưu trữ trong cơ sở dữ liệu. Thách thức ở đây là hỗ trợ đồng bộ hóa giữa nhiều máy chủ ứng dụng chia sẻ dữ liệu này (tệp đã tải lên và phiên người dùng).

Để mở rộng quy mô ứng dụng này, bạn cần tách biệt máy chủ web và máy chủ cơ sở dữ liệu. Do đó, các nút sẽ xuất hiện trong cụm chia sẻ máy chủ cơ sở dữ liệu. Điều này sẽ tăng hiệu suất ứng dụng bằng cách giảm tải cho máy chủ web.

Trong tương lai, bạn có thể định cấu hình cân bằng tải; Bạn có thể đọc về điều này trong hướng dẫn ""

Tính nhất quán của phiên

Khi máy chủ web và cơ sở dữ liệu được tách biệt, bạn cần tập trung vào việc xử lý các phiên của người dùng.

Cơ sở dữ liệu quan hệ và hệ thống tập tin mạng

Dữ liệu phiên thường được lưu trữ trong Cơ sở dữ liệu quan hệ data (chẳng hạn như MySQL), vì những cơ sở dữ liệu này rất dễ cấu hình.

Tuy nhiên, giải pháp này không đáng tin cậy nhất vì trong trường hợp này tải sẽ tăng lên. Máy chủ phải nhập vào cơ sở dữ liệu mỗi thao tác đọc và ghi cho mỗi yêu cầu riêng và trong trường hợp lưu lượng truy cập tăng đột ngột, cơ sở dữ liệu có xu hướng bị lỗi trước các thành phần khác.

Hệ thống tệp mạng là một cách đơn giản khác để lưu trữ dữ liệu; không cần phải thay đổi cơ sở dữ liệu văn bản nguồn, Tuy nhiên hệ thống mạng xử lý các hoạt động I/O rất chậm và điều này có thể có tác động tiêu cực đến hiệu suất ứng dụng.

Phiên dính

Phiên cố định được triển khai trên bộ cân bằng tải và không yêu cầu bất kỳ thay đổi nào đối với các nút ứng dụng. Đây là phương pháp thuận tiện nhất để xử lý phiên của người dùng. Bộ cân bằng tải sẽ luôn hướng người dùng đến cùng một máy chủ, loại bỏ nhu cầu phân phối dữ liệu phiên giữa các nút còn lại trong cụm.

Tuy nhiên, giải pháp này cũng có một nhược điểm nghiêm trọng. Bây giờ bộ cân bằng không chỉ phân phối tải mà còn có nhiệm vụ bổ sung. Điều này có thể ảnh hưởng đến hiệu suất của nó và khiến nó bị hỏng.

Máy chủ Memcached và Redis

Bạn cũng có thể cấu hình một hoặc nhiều máy chủ bổ sungđể xử lý các phiên. Đây là nhiều nhất cách đáng tin cậy giải quyết các vấn đề liên quan đến xử lý phiên.

Hành động cuối cùng

Mở rộng quy mô theo chiều ngang của một ứng dụng lúc đầu có vẻ như là một giải pháp rất phức tạp và khó hiểu, nhưng nó giúp loại bỏ các vấn đề giao thông nghiêm trọng. Điều chính là học cách làm việc với bộ cân bằng tải để hiểu thành phần nào yêu cầu cấu hình bổ sung.

Hiệu suất mở rộng và ứng dụng có liên quan rất chặt chẽ. Tất nhiên, không phải tất cả các ứng dụng và trang web đều cần mở rộng quy mô. Tuy nhiên, tốt hơn hết bạn nên suy nghĩ trước về điều này, tốt nhất là ở giai đoạn phát triển ứng dụng.

Thẻ: ,