Tất cả chúng ta đều yêu thích những câu chuyện. Chúng tôi thích ngồi quanh đống lửa và nói về những chiến thắng, trận chiến trong quá khứ hoặc đơn giản là kinh nghiệm làm việc của chúng tôi.
Hôm nay chính là một ngày như vậy. Và ngay cả khi bạn không ở bên đống lửa lúc này, chúng tôi vẫn có một câu chuyện dành cho bạn. Câu chuyện về cách chúng tôi bắt đầu làm việc với bộ nhớ trên Tarantool.
Ngày xửa ngày xưa, công ty của chúng tôi có một vài “tảng đá nguyên khối” và một “trần nhà” cho tất cả mọi người, mà những khối đá nguyên khối này đang dần dần tiếp cận, hạn chế đường bay của công ty chúng tôi, sự phát triển của chúng tôi. Và có một sự hiểu biết rõ ràng: một ngày nào đó chúng ta sẽ chạm mạnh vào mức trần này.
Hiện nay hệ tư tưởng phổ biến về việc tách biệt mọi thứ và mọi người, từ thiết bị đến logic kinh doanh. Kết quả là, chẳng hạn, chúng tôi có hai DC thực tế độc lập ở cấp độ mạng. Và rồi mọi thứ đã hoàn toàn khác.
Ngày nay có rất nhiều công cụ, công cụ thực hiện thay đổi dưới dạng CI/CD, K8S, v.v. Vào thời “đá nguyên khối”, chúng ta không cần quá nhiều từ nước ngoài. Chỉ cần sửa lại “bộ nhớ” trong cơ sở dữ liệu là đủ.
Nhưng thời gian trôi qua và số lượng yêu cầu cũng tăng theo, đôi khi khiến RPS vượt quá khả năng của chúng tôi. Với sự gia nhập thị trường của các quốc gia CIS, tải trên bộ xử lý cơ sở dữ liệu của khối nguyên khối đầu tiên không giảm xuống dưới 90% và RPS vẫn ở mức 2400. Và đây không chỉ là những bộ chọn nhỏ mà còn là những truy vấn khổng lồ với một một loạt các kiểm tra và THAM GIA có thể chạy gần một nửa dữ liệu trên nền IO lớn.
Khi đợt giảm giá Thứ Sáu Đen chính thức bắt đầu xuất hiện - và Wildberries là một trong những nơi đầu tiên tổ chức chúng ở Nga - tình hình trở nên hoàn toàn đáng buồn. Rốt cuộc, tải trọng vào những ngày như vậy tăng lên gấp ba lần.
Ôi, những “thời nguyên khối” này! Tôi chắc chắn rằng bạn đã trải qua điều gì đó tương tự và bạn vẫn không thể hiểu tại sao điều này lại có thể xảy ra với mình.
Bạn có thể làm gì - thời trang vốn có trong công nghệ. Khoảng 5 năm trước, chúng tôi đã phải suy nghĩ lại một trong những mod này dưới dạng một trang web hiện có trên máy chủ .NET và MS SQL, nơi lưu trữ cẩn thận tất cả logic của chính trang web đó. Tôi đã giữ nó cẩn thận đến nỗi việc cưa một khối đá nguyên khối như vậy hóa ra là một thú vui lâu dài và không hề dễ dàng chút nào.
Một sự lạc đề nhỏ.
Tại nhiều sự kiện khác nhau, tôi nói: "nếu bạn không nhìn thấy một tảng đá nguyên khối, thì bạn đã không trưởng thành!" Tôi quan tâm đến ý kiến của bạn về vấn đề này, xin vui lòng viết nó trong phần bình luận.
Tiếng sấm
Hãy quay trở lại với "ngọn lửa" của chúng ta. Để phân phối tải chức năng “nguyên khối”, chúng tôi quyết định chia hệ thống thành các vi dịch vụ dựa trên công nghệ nguồn mở. Bởi vì, ở mức tối thiểu, chúng rẻ hơn khi mở rộng quy mô. Và chúng tôi hiểu 100% rằng chúng tôi sẽ phải mở rộng quy mô (và rất nhiều). Rốt cuộc, vào thời điểm đó đã có thể thâm nhập thị trường các nước lân cận, và số lượng đăng ký cũng như số lượng đơn đặt hàng bắt đầu tăng mạnh hơn nữa.
Sau khi phân tích các ứng cử viên đầu tiên chuyển từ nguyên khối sang dịch vụ vi mô, chúng tôi nhận ra rằng 80% văn bản trong đó đến từ hệ thống văn phòng hỗ trợ và việc đọc từ văn phòng chính. Trước hết, điều này liên quan đến một số hệ thống con quan trọng đối với chúng tôi - dữ liệu người dùng và hệ thống tính toán giá thành cuối cùng của hàng hóa dựa trên thông tin về các phiếu giảm giá và giảm giá bổ sung cho khách hàng.
Đã thụt lề. Bây giờ thật đáng sợ khi tưởng tượng, nhưng ngoài các hệ thống con nêu trên, danh mục sản phẩm, giỏ hàng của người dùng, hệ thống tìm kiếm sản phẩm, hệ thống lọc danh mục sản phẩm và các loại hệ thống đề xuất khác nhau cũng đã bị xóa khỏi khối nguyên khối của chúng tôi. Đối với hoạt động của mỗi người trong số họ, có những lớp hệ thống được điều chỉnh hẹp riêng biệt, nhưng ngày xưa tất cả họ đều sống trong một “ngôi nhà”.
Chúng tôi ngay lập tức lên kế hoạch chuyển dữ liệu về khách hàng của mình sang hệ thống phân chia. Việc loại bỏ chức năng tính toán chi phí cuối cùng của hàng hóa đòi hỏi khả năng mở rộng tốt để đọc vì nó tạo ra tải RPS lớn nhất và khó triển khai nhất đối với cơ sở dữ liệu (rất nhiều dữ liệu liên quan đến quá trình tính toán).
Kết quả là chúng tôi đã nghĩ ra một kế hoạch rất phù hợp với Tarantool.
Vào thời điểm đó, để vận hành các vi dịch vụ, các phương án làm việc với một số trung tâm dữ liệu trên máy ảo và phần cứng đã được chọn. Như được hiển thị trong hình, các tùy chọn sao chép Tarantool đã được áp dụng ở cả chế độ chủ-chính và chủ-nô lệ.
Ngành kiến trúc. Tùy chọn 1. Dịch vụ người dùng
Tại thời điểm hiện tại, có 24 phân đoạn, mỗi phân đoạn có 2 phiên bản (một cho mỗi DC), tất cả đều ở chế độ chính-chính.
Phía trên cơ sở dữ liệu là các ứng dụng truy cập vào bản sao cơ sở dữ liệu. Các ứng dụng hoạt động với Tarantool thông qua thư viện tùy chỉnh của chúng tôi, thư viện này triển khai giao diện trình điều khiển Tarantool Go. Cô ấy nhìn thấy tất cả các bản sao và có thể làm việc với chủ để đọc và viết. Về cơ bản, nó triển khai mô hình bộ bản sao, bổ sung logic để chọn bản sao, thực hiện thử lại, bộ ngắt mạch và giới hạn tốc độ.
Trong trường hợp này, có thể định cấu hình chính sách lựa chọn bản sao trong bối cảnh phân đoạn. Ví dụ: quay vòng.
Ngành kiến trúc. Phương án 2. Dịch vụ tính giá thành cuối cùng của hàng hóa
Một vài tháng trước, hầu hết các yêu cầu tính toán chi phí hàng hóa cuối cùng đều thuộc về một dịch vụ mới, về nguyên tắc, hoạt động mà không cần cơ sở dữ liệu, nhưng cách đây một thời gian, mọi thứ đã được xử lý 100% bởi một dịch vụ có Tarantool.
Cơ sở dữ liệu dịch vụ bao gồm 4 bản chính trong đó bộ đồng bộ hóa thu thập dữ liệu và mỗi bản gốc sao chép này sẽ phân phối dữ liệu đến các bản sao chỉ đọc. Mỗi bản gốc có khoảng 15 bản sao như vậy.
Trong sơ đồ thứ nhất hoặc thứ hai, nếu không có một DC, ứng dụng có thể nhận dữ liệu trong sơ đồ thứ hai.
Điều đáng chú ý là việc sao chép trong Tarantool khá linh hoạt và có thể được cấu hình khi chạy. Trong các hệ thống khác, khó khăn nảy sinh. Ví dụ: việc thay đổi các tham số max_wal_senders và max_replication_slots trong PostgreSQL yêu cầu khởi động lại trình hướng dẫn, điều này trong một số trường hợp có thể dẫn đến việc cắt đứt các kết nối giữa ứng dụng và DBMS.
Trốn tìm!
Tại sao chúng ta không làm “như người bình thường” mà lại chọn cách không điển hình? Nó phụ thuộc vào những gì được coi là bình thường. Nhiều người thường tạo một cụm từ Mongo và trải rộng nó trên ba DC được phân phối theo địa lý.
Vào thời điểm đó, chúng tôi đã có hai dự án Redis. Đầu tiên là bộ đệm và thứ hai là bộ lưu trữ liên tục cho dữ liệu không quá quan trọng. Mọi chuyện khá khó khăn với anh ấy, một phần là do lỗi của chúng tôi. Đôi khi có một khối lượng khá lớn trong chìa khóa và đôi khi trang web trở nên không hoạt động tốt. Chúng tôi đã sử dụng hệ thống này trong phiên bản master-slave. Và có nhiều trường hợp xảy ra sự cố với bản gốc và bản sao bị hỏng.
Nghĩa là, Redis phù hợp với các tác vụ không có trạng thái, không phải các tác vụ có trạng thái. Về nguyên tắc, nó cho phép giải quyết hầu hết các vấn đề, nhưng chỉ khi chúng là giải pháp khóa-giá trị với một cặp chỉ mục. Nhưng Redis lúc đó khá buồn với sự kiên trì và nhân rộng. Ngoài ra, còn có những phàn nàn về hiệu suất.
Chúng tôi đã nghĩ về MySQL và PostgreSQL. Nhưng bằng cách nào đó, sản phẩm đầu tiên không phù hợp với chúng tôi và sản phẩm thứ hai bản thân nó đã là một sản phẩm khá phức tạp và sẽ không phù hợp nếu xây dựng các dịch vụ đơn giản trên đó.
Chúng tôi đã thử RIAK, Cassandra, thậm chí cả cơ sở dữ liệu đồ thị. Đây đều là những giải pháp khá thích hợp, không phù hợp với vai trò của một công cụ phổ quát chung để tạo ra dịch vụ.
Cuối cùng chúng tôi đã quyết định sử dụng Tarantool.
Chúng tôi đã chuyển sang nó khi nó ở phiên bản 1.6. Chúng tôi quan tâm đến nó bởi sự cộng sinh của khóa-giá trị và chức năng của cơ sở dữ liệu quan hệ. Có các chỉ mục phụ, giao dịch và không gian, chúng giống như bảng, nhưng không đơn giản, bạn có thể lưu trữ số lượng cột khác nhau trong đó. Nhưng tính năng nổi bật của Tarantool là các chỉ mục phụ được kết hợp với khóa-giá trị và tính giao dịch.
Cộng đồng nói tiếng Nga phản ứng nhanh, sẵn sàng trợ giúp trong trò chuyện cũng đóng một vai trò nào đó. Chúng tôi tích cực sử dụng điều này và trực tiếp trong cuộc trò chuyện. Và đừng quên sự kiên trì tử tế mà không mắc sai lầm và sai lầm rõ ràng. Nếu bạn nhìn lại lịch sử của chúng tôi với Tarantool, chúng tôi đã gặp rất nhiều khó khăn và thất bại khi sao chép, nhưng chúng tôi chưa bao giờ bị mất dữ liệu do lỗi của nó!
Việc triển khai có sự khởi đầu khó khăn
Vào thời điểm đó, nền tảng phát triển chính của chúng tôi là .NET, không có trình kết nối nào cho Tarantool. Chúng tôi ngay lập tức bắt đầu làm điều gì đó trong Go. Nó cũng hoạt động tốt với Lua. Vấn đề chính vào thời điểm đó là việc gỡ lỗi: trong .NET mọi thứ đều tuyệt vời với điều này, nhưng sau đó thật khó để lao vào thế giới của Lua nhúng, khi bạn không có cách gỡ lỗi nào ngoại trừ nhật ký. Ngoài ra, vì lý do nào đó mà việc sao chép định kỳ bị hỏng nên tôi phải đi sâu vào cấu trúc của động cơ Tarantool. Cuộc trò chuyện đã giúp giải quyết vấn đề này và ở một mức độ thấp hơn là tài liệu; Vào thời điểm đó, tài liệu là như vậy.
Vì vậy, trong vài tháng, tôi đã cố gắng suy nghĩ lại và nhận được kết quả tốt khi làm việc với Tarantool. Chúng tôi đã biên soạn các phát triển tham khảo trong git giúp hình thành các vi dịch vụ mới. Ví dụ: khi nảy sinh một nhiệm vụ: tạo một microservice khác, nhà phát triển đã xem mã nguồn của giải pháp tham chiếu trong kho lưu trữ và không mất quá một tuần để tạo một microservice mới.
Đây là những thời điểm đặc biệt. Thông thường, bạn có thể đến gặp quản trị viên ở bàn bên cạnh và hỏi: “Cho tôi một máy ảo.” Khoảng ba mươi phút sau xe đã đến chỗ bạn. Bạn đã tự kết nối, cài đặt mọi thứ và lưu lượng truy cập đã được gửi đến bạn.
Ngày nay, điều này sẽ không còn hoạt động nữa: bạn cần thêm tính năng giám sát và ghi nhật ký vào dịch vụ, bao gồm chức năng bằng các thử nghiệm, đặt hàng máy ảo hoặc giao hàng tới Kuber, v.v. Nhìn chung thì cách này sẽ tốt hơn, mặc dù sẽ mất nhiều thời gian hơn và rắc rối hơn.
Chia ra và cai trị. Có chuyện gì với Lua vậy?
Có một vấn đề nan giải nghiêm trọng: một số nhóm không thể triển khai các thay đổi một cách đáng tin cậy đối với một dịch vụ có nhiều logic trong Lua. Điều này thường đi kèm với dịch vụ không hoạt động.
Đó là, các nhà phát triển đang chuẩn bị một số loại thay đổi. Tarantool bắt đầu thực hiện quá trình di chuyển, nhưng bản sao vẫn có mã cũ; Một số DDL hoặc thứ gì đó khác đến đó thông qua việc sao chép và mã chỉ đơn giản là bị hỏng vì nó không được tính đến. Do đó, quy trình cập nhật dành cho quản trị viên được trình bày trên tờ A4: dừng sao chép, cập nhật cái này, bật sao chép, tắt ở đây, cập nhật ở đó. Cơn ác mộng!
Kết quả là hiện nay chúng ta thường cố gắng không làm gì trong Lua. Chỉ cần sử dụng iproto (một giao thức nhị phân để tương tác với máy chủ) và thế là xong. Có lẽ đây là sự thiếu kiến thức của các nhà phát triển, nhưng từ quan điểm này, hệ thống rất phức tạp.
Chúng tôi không phải lúc nào cũng mù quáng làm theo kịch bản này. Ngày nay chúng ta không có màu đen và trắng: hoặc mọi thứ đều ở Lua hoặc mọi thứ đều ở Go. Chúng tôi đã hiểu cách có thể kết hợp chúng để không gặp phải vấn đề di chuyển sau này.
Tarantool hiện đang ở đâu?
Tarantool được sử dụng trong dịch vụ tính toán giá thành cuối cùng của hàng hóa có tính đến các phiếu giảm giá, còn được gọi là “Promoter”. Như tôi đã nói trước đó, anh ấy hiện đã nghỉ hưu: anh ấy đang được thay thế bằng một dịch vụ danh mục mới với giá được tính trước, nhưng sáu tháng trước, tất cả các tính toán đều được thực hiện trong Promoterizer. Trước đây, một nửa logic của nó được viết bằng Lua. Hai năm trước, dịch vụ này đã được biến thành một cơ sở lưu trữ và logic đã được viết lại trong Go, vì cơ chế giảm giá đã thay đổi một chút và dịch vụ thiếu hiệu suất.
Một trong những dịch vụ quan trọng nhất là hồ sơ người dùng. Nghĩa là, tất cả người dùng Wildberries đều được lưu trữ trong Tarantool và có khoảng 50 triệu người trong số họ. Một hệ thống được phân chia theo ID người dùng, được phân bổ trên một số DC được kết nối với dịch vụ Go.
Theo RPS, Promoter từng dẫn đầu khi đạt 6 nghìn yêu cầu. Có thời điểm chúng tôi có 50-60 bản. Hiện dẫn đầu về RPS là hồ sơ người dùng, khoảng 12 nghìn. Dịch vụ này sử dụng phân đoạn tùy chỉnh, chia cho các phạm vi ID người dùng. Dịch vụ phục vụ hơn 20 máy, nhưng con số này là quá nhiều; chúng tôi dự định giảm nguồn lực được phân bổ vì sức chứa 4-5 máy là đủ cho dịch vụ này.
Dịch vụ phiên là dịch vụ đầu tiên của chúng tôi trên vshard và Cartridge. Việc thiết lập vshard và cập nhật Cartridge đòi hỏi chúng tôi phải nỗ lực một chút, nhưng cuối cùng thì mọi thứ đều ổn.
Dịch vụ hiển thị các biểu ngữ khác nhau trên trang web và trong ứng dụng di động là một trong những dịch vụ đầu tiên được phát hành trực tiếp trên Tarantool. Dịch vụ này đáng chú ý ở chỗ nó đã 6-7 năm tuổi, vẫn đang hoạt động và chưa bao giờ được khởi động lại. Bản sao Master-Master đã được sử dụng. Không có gì từng bị phá vỡ.
Có một ví dụ về việc sử dụng Tarantool cho chức năng tham khảo nhanh trong hệ thống kho nhằm kiểm tra nhanh thông tin trong một số trường hợp. Chúng tôi đã cố gắng sử dụng Redis cho việc này, nhưng dữ liệu trong bộ nhớ chiếm nhiều dung lượng hơn Tarantool.
Các dịch vụ về danh sách chờ, đăng ký của khách hàng, những câu chuyện thời thượng hiện nay và hàng hóa trả chậm cũng hoạt động với Tarantool. Dịch vụ cuối cùng trong bộ nhớ chiếm khoảng 120 GB. Đây là dịch vụ toàn diện nhất ở trên.
Kết luận
Nhờ các chỉ mục phụ kết hợp với khóa-giá trị và tính giao dịch, Tarantool rất phù hợp với kiến trúc dựa trên vi dịch vụ. Tuy nhiên, chúng tôi gặp khó khăn khi triển khai các thay đổi đối với các dịch vụ có nhiều logic trong Lua - các dịch vụ thường ngừng hoạt động. Chúng tôi đã không thể khắc phục điều này và theo thời gian, chúng tôi đã đi đến những cách kết hợp khác nhau giữa Lua và Go: chúng tôi biết nơi nào nên sử dụng một ngôn ngữ và nơi nào nên sử dụng ngôn ngữ khác.
Những gì khác để đọc về chủ đề này
- Chúng tôi tạo một ứng dụng tải cao từ đầu bằng Tarantool
- Sự lựa chọn lãnh đạo đáng tin cậy trong Tarantool Cartridge
- Kênh Telegram Tarantool với tin tức về sản phẩm
- Thảo luận về Tarantool trong phần trò chuyện cộng đồng
Nguồn: www.habr.com
