Tại sao một tập đoàn như MegaFon lại cần Tarantool trong thanh toán? Nhìn từ bên ngoài, có vẻ như người bán hàng thường đến, mang theo một loại hộp lớn nào đó, cắm phích cắm vào ổ cắm - và đó là hóa đơn! Điều này đã từng xảy ra, nhưng bây giờ nó đã trở nên cổ xưa và những loài khủng long như vậy đã tuyệt chủng hoặc đang tuyệt chủng. Ban đầu, thanh toán là một hệ thống phát hành hóa đơn - máy đếm hoặc máy tính. Trong viễn thông hiện đại, đây là hệ thống tự động hóa cho toàn bộ vòng đời tương tác với người đăng ký từ khi ký kết hợp đồng cho đến khi chấm dứt, bao gồm thanh toán theo thời gian thực, chấp nhận thanh toán và hơn thế nữa. Việc thanh toán ở các công ty viễn thông giống như một robot chiến đấu - to lớn, mạnh mẽ và được trang bị đầy đủ vũ khí.
Tarantool có liên quan gì đến nó? Họ sẽ nói về nó Oleg Ivlev и Andrey Knyazev. Oleg là kiến trúc sư trưởng của công ty Với kinh nghiệm dày dặn làm việc tại các công ty nước ngoài, Andrey hiện là giám đốc hệ thống kinh doanh. Từ bản ghi báo cáo của họ về bạn sẽ tìm hiểu lý do tại sao R&D lại cần thiết trong các tập đoàn, Tarantool là gì, sự bế tắc của việc mở rộng quy mô theo chiều dọc và toàn cầu hóa đã trở thành điều kiện tiên quyết cho sự xuất hiện của cơ sở dữ liệu này trong công ty như thế nào, về những thách thức công nghệ, chuyển đổi kiến trúc và cách technostack của MegaFon tương tự như Netflix , Google và Amazon.
Dự án "Thanh toán thống nhất"
Dự án được đề cập có tên là “Thanh toán thống nhất”. Chính tại đây, Tarantool đã thể hiện những phẩm chất tốt nhất của mình.
Sự tăng trưởng về năng suất của thiết bị Hi-End không theo kịp tốc độ tăng trưởng của cơ sở thuê bao và sự tăng trưởng về số lượng dịch vụ; sự tăng trưởng hơn nữa về số lượng thuê bao và dịch vụ được kỳ vọng do M2M, IoT và các tính năng chi nhánh dẫn đầu đến sự suy giảm về thời gian đưa sản phẩm ra thị trường. Công ty quyết định tạo ra một hệ thống kinh doanh hợp nhất với kiến trúc mô-đun độc đáo đẳng cấp thế giới, thay vì 8 hệ thống thanh toán khác nhau hiện tại.
MegaFon là tám công ty trong một. Năm 2009, quá trình tái tổ chức đã hoàn tất: các chi nhánh trên khắp nước Nga sáp nhập thành một công ty duy nhất, MegaFon OJSC (nay là PJSC). Do đó, công ty có 8 hệ thống thanh toán với các giải pháp “tùy chỉnh” riêng, các tính năng của chi nhánh và các cơ cấu tổ chức, CNTT và tiếp thị khác nhau.
Mọi thứ đều ổn cho đến khi chúng tôi phải tung ra một sản phẩm chung của liên bang. Ở đây đã nảy sinh rất nhiều khó khăn: đối với một số người, thuế quan được làm tròn, đối với những người khác, làm tròn xuống và đối với những người khác - dựa trên giá trị trung bình số học. Có hàng ngàn khoảnh khắc như vậy.
Mặc dù thực tế là chỉ có một phiên bản của hệ thống thanh toán, một nhà cung cấp, nhưng các cài đặt rất khác nhau nên phải mất một thời gian dài để tập hợp lại. Chúng tôi đã cố gắng giảm số lượng của họ và gặp phải vấn đề thứ hai quen thuộc với nhiều tập đoàn.
Chia tỷ lệ dọc. Ngay cả phần cứng tuyệt vời nhất vào thời điểm đó cũng không đáp ứng được nhu cầu. Chúng tôi đã sử dụng thiết bị Hewlett-Packard của dòng Superdome Hi-End nhưng nó không đáp ứng được nhu cầu của cả hai chi nhánh. Tôi muốn mở rộng quy mô theo chiều ngang mà không cần chi phí vận hành và đầu tư vốn lớn.
Kỳ vọng tăng trưởng về số lượng thuê bao và dịch vụ. Các nhà tư vấn từ lâu đã đưa những câu chuyện về IoT và M2M đến với thế giới viễn thông: sẽ đến lúc mọi điện thoại và bàn ủi đều có một thẻ SIM và hai cái trong tủ lạnh. Hôm nay chúng tôi có một số lượng người đăng ký, nhưng trong tương lai gần sẽ có nhiều hơn nữa.
Những thách thức về công nghệ
Bốn lý do này đã thúc đẩy chúng tôi thực hiện những thay đổi nghiêm túc. Có sự lựa chọn giữa việc nâng cấp hệ thống và thiết kế lại từ đầu. Chúng tôi đã suy nghĩ rất lâu, đưa ra những quyết định nghiêm túc, đấu thầu. Do đó, chúng tôi quyết định thiết kế ngay từ đầu và đón nhận những thử thách thú vị - thử thách công nghệ.
Khả năng mở rộng
Nếu là trước đây, hãy nói, hãy nói 8 hóa đơn cho 15 triệu thuê bao, và bây giờ lẽ ra nó đã hoạt động 100 triệu người đăng ký và hơn thế nữa - tải cao hơn một bậc.
Chúng tôi đã có quy mô tương đương với những người chơi Internet lớn như Mail.ru hoặc Netflix.
Nhưng động thái tiếp theo nhằm tăng lượng tải và số lượng người đăng ký đã đặt ra những thách thức nghiêm trọng cho chúng tôi.
Địa lý nước ta rộng lớn
Giữa Kaliningrad và Vladivostok 7500 km và 10 múi giờ. Tốc độ ánh sáng là hữu hạn và ở những khoảng cách như vậy độ trễ đã rất đáng kể. 150 ms trên các kênh quang hiện đại thú vị nhất là quá nhiều cho việc thanh toán theo thời gian thực, đặc biệt là trong lĩnh vực viễn thông ở Nga hiện nay. Ngoài ra, bạn cần cập nhật trong một ngày làm việc và với các múi giờ khác nhau thì đây là một vấn đề.
Chúng tôi không chỉ cung cấp dịch vụ với một khoản phí đăng ký, chúng tôi còn có các mức thuế, gói phức tạp và nhiều điều chỉnh khác nhau. Chúng ta không chỉ cần cho phép hoặc từ chối người đăng ký nói chuyện mà còn cho anh ta một hạn ngạch nhất định - tính toán các cuộc gọi và hành động trong thời gian thực để anh ta không chú ý.
khả năng chịu lỗi
Đây là mặt khác của sự tập trung hóa.
Nếu chúng tôi thu thập tất cả người đăng ký vào một hệ thống thì bất kỳ sự kiện khẩn cấp và thảm họa nào cũng sẽ là thảm họa đối với doanh nghiệp. Do đó, chúng tôi thiết kế hệ thống theo cách loại bỏ tác động của sự cố đối với toàn bộ cơ sở thuê bao.
Đây lại là hậu quả của việc từ chối mở rộng quy mô theo chiều dọc. Khi mở rộng quy mô theo chiều ngang, chúng tôi đã tăng số lượng máy chủ từ hàng trăm lên hàng nghìn. Chúng cần được quản lý và hoán đổi cho nhau, tự động sao lưu cơ sở hạ tầng CNTT và khôi phục hệ thống phân tán.
Chúng tôi phải đối mặt với những thử thách thú vị như vậy. Chúng tôi đã thiết kế hệ thống và tại thời điểm đó, chúng tôi đã cố gắng tìm ra các phương pháp thực hành tốt nhất trên toàn cầu để kiểm tra xem chúng tôi đang theo xu hướng như thế nào, chúng tôi theo đuổi các công nghệ tiên tiến đến mức nào.
Kinh nghiệm thế giới
Đáng ngạc nhiên là chúng tôi không tìm thấy một tài liệu tham khảo nào trong lĩnh vực viễn thông toàn cầu.
Châu Âu đã tụt hậu về số lượng thuê bao và quy mô, Hoa Kỳ - về mức độ đồng đều của thuế quan. Chúng tôi đã xem xét một số ở Trung Quốc và tìm thấy một số ở Ấn Độ và thuê các chuyên gia từ Vodafone Ấn Độ.
Để phân tích kiến trúc, chúng tôi đã tập hợp Dream Team do IBM lãnh đạo - những kiến trúc sư từ các lĩnh vực khác nhau. Những người này có thể đánh giá đầy đủ những gì chúng tôi đang làm và mang lại những kiến thức nhất định cho kiến trúc của chúng tôi.
Quy mô
Một vài con số mang tính minh họa.
Chúng tôi thiết kế hệ thống cho 80 triệu thuê bao với trữ lượng XNUMX tỷ. Đây là cách chúng tôi loại bỏ các ngưỡng trong tương lai. Điều này không phải vì chúng ta sắp chiếm lĩnh Trung Quốc mà là do sự tấn công dữ dội của IoT và M2M.
300 triệu tài liệu được xử lý trong thời gian thực. Mặc dù chúng tôi có 80 triệu người đăng ký, nhưng chúng tôi làm việc với cả khách hàng tiềm năng và những khách hàng đã rời bỏ chúng tôi nếu chúng tôi cần thu các khoản phải thu. Do đó, khối lượng thực tế lớn hơn đáng kể.
2 tỷ giao dịch Số dư thay đổi hàng ngày - đây là các khoản thanh toán, phí, cuộc gọi và các sự kiện khác. 200 TB dữ liệu đang tích cực thay đổi, thay đổi chậm hơn một chút 8 PB dữ liệuvà đây không phải là bản lưu trữ mà là dữ liệu trực tiếp trong một lần thanh toán. Chia tỷ lệ theo trung tâm dữ liệu - 5 nghìn máy chủ trên 14 trang web.
ngăn xếp công nghệ
Khi chúng tôi lên kế hoạch kiến trúc và bắt đầu lắp ráp hệ thống, chúng tôi đã nhập khẩu những công nghệ tiên tiến và thú vị nhất. Kết quả là một tập hợp công nghệ quen thuộc với bất kỳ người chơi Internet và tập đoàn nào tạo ra các hệ thống có tải trọng cao.
Ngăn xếp tương tự như ngăn xếp của những người chơi lớn khác: Netflix, Twitter, Viber. Nó bao gồm 6 thành phần, nhưng chúng tôi muốn rút gọn và thống nhất nó.
Tính linh hoạt là tốt, nhưng trong một tập đoàn lớn thì không thể thiếu sự thống nhất.
Chúng tôi sẽ không thay đổi cùng một Oracle thành Tarantool. Trong thực tế của các công ty lớn, đây là một điều không tưởng, hay một cuộc thập tự chinh kéo dài 5-10 năm với kết quả không rõ ràng. Nhưng Cassandra và Couchbase có thể dễ dàng được thay thế bằng Tarantool và đó là điều chúng tôi đang phấn đấu.
Tại sao lại là Tarantool?
Có 4 tiêu chí đơn giản tại sao chúng tôi chọn cơ sở dữ liệu này.
tốc độ. Chúng tôi đã tiến hành kiểm tra tải trên các hệ thống công nghiệp MegaFon. Tarantool đã thắng - nó cho thấy hiệu suất tốt nhất.
Điều này không có nghĩa là các hệ thống khác không đáp ứng được nhu cầu của MegaFon. Các giải pháp bộ nhớ hiện tại hiệu quả đến mức dự trữ của công ty là quá đủ. Nhưng chúng tôi quan tâm đến việc làm việc với một người dẫn đầu chứ không phải với một người đang tụt lại phía sau, kể cả trong bài kiểm tra tải.
Tarantool đáp ứng nhu cầu của công ty ngay cả trong thời gian dài.
chi phí TCO. Việc hỗ trợ Couchbase trên các tập MegaFon tốn rất nhiều tiền, nhưng với Tarantool, tình hình dễ chịu hơn nhiều và chúng có chức năng tương tự nhau.
Một tính năng thú vị khác ảnh hưởng một chút đến lựa chọn của chúng tôi là Tarantool hoạt động với bộ nhớ tốt hơn các cơ sở dữ liệu khác. Anh ấy cho thấy hiệu quả tối đa.
Độ tin cậy. MegaFon đầu tư vào độ tin cậy, có lẽ hơn bất kỳ ai khác. Vì vậy, khi xem xét Tarantool, chúng tôi nhận ra rằng chúng tôi phải làm cho nó đáp ứng được yêu cầu của mình.
Chúng tôi đã đầu tư thời gian và tài chính của mình và cùng với Mail.ru, chúng tôi đã tạo ra một phiên bản doanh nghiệp, hiện được sử dụng ở một số công ty khác.
Tarantool-enterprise hoàn toàn làm chúng tôi hài lòng về tính bảo mật, độ tin cậy và ghi nhật ký.
công ty
Điều quan trọng nhất đối với tôi là liên hệ trực tiếp với nhà phát triển. Đây chính xác là những gì mà những kẻ ở Tarantool đã hối lộ.
Nếu bạn đến gặp một người chơi, đặc biệt là người làm việc với khách hàng cố định và nói rằng bạn cần cơ sở dữ liệu để có thể thực hiện điều này, điều này và điều này, anh ta thường trả lời:
- Được rồi, hãy đặt các yêu cầu ở cuối đống đó - một ngày nào đó, chúng ta có thể sẽ đạt được chúng.
Nhiều người có lộ trình trong 2-3 năm tới và gần như không thể tích hợp ở đó, nhưng các nhà phát triển Tarantool quyến rũ với sự cởi mở của họ, không chỉ từ MegaFon, và khả năng điều chỉnh hệ thống của họ cho phù hợp với khách hàng. Thật tuyệt và chúng tôi thực sự thích nó.
Nơi chúng tôi sử dụng Tarantool
Chúng tôi sử dụng Tarantool trong một số phần. Đầu tiên là trong phi công, mà chúng tôi đã thực hiện trên hệ thống thư mục địa chỉ. Đã có lúc tôi muốn nó trở thành một hệ thống tương tự như Yandex.Maps và Google Maps, nhưng hóa ra nó hơi khác một chút.
Ví dụ: danh mục địa chỉ trong giao diện bán hàng. Trên Oracle, việc tìm kiếm địa chỉ mong muốn mất 12-13 giây. - những con số khó chịu. Khi chúng tôi chuyển sang Tarantool, thay thế Oracle bằng một cơ sở dữ liệu khác trong bảng điều khiển và thực hiện cùng một tìm kiếm, chúng tôi nhận được tốc độ tăng gấp 200 lần! Thành phố hiện lên sau chữ cái thứ ba. Bây giờ chúng tôi đang điều chỉnh giao diện để điều này xảy ra sau giao diện đầu tiên. Tuy nhiên, tốc độ phản hồi hoàn toàn khác - mili giây thay vì giây.
Ứng dụng thứ hai là một chủ đề thời thượng có tên IT hai tốc độ. Điều này là do các nhà tư vấn từ mọi nơi đều nói rằng các tập đoàn nên đến đó.
Có một lớp cơ sở hạ tầng, bên trên nó có các miền, ví dụ như hệ thống thanh toán như viễn thông, hệ thống công ty, báo cáo công ty. Đây là cốt lõi không cần phải chạm vào. Điều đó tất nhiên là có thể, nhưng đảm bảo chất lượng một cách hoang tưởng, vì nó mang lại tiền cho tập đoàn.
Tiếp theo là lớp vi dịch vụ - yếu tố tạo nên sự khác biệt giữa người vận hành và người chơi khác. Các vi dịch vụ có thể được tạo nhanh chóng dựa trên một số bộ đệm nhất định, đưa dữ liệu từ các miền khác nhau vào đó. Đây trường thí nghiệm — nếu có gì đó không ổn, tôi đóng một microservice và mở một microservice khác. Điều này giúp tăng thời gian tiếp thị thực sự và tăng độ tin cậy cũng như tốc độ của công ty.
Dịch vụ vi mô có lẽ là vai trò chính của Tarantool tại MegaFon.
Nơi chúng tôi dự định sử dụng Tarantool
Nếu chúng ta so sánh dự án thanh toán thành công của mình với các chương trình chuyển đổi tại Deutsche Telekom, Svyazcom, Vodafone India, thì nó năng động và sáng tạo một cách đáng ngạc nhiên. Trong quá trình triển khai dự án này, không chỉ MegaFon và cấu trúc của nó đã được chuyển đổi mà cả Tarantool-enterprise cũng xuất hiện tại Mail.ru và nhà cung cấp Nexign của chúng tôi (trước đây là Peter-Service) - BSS Box (một giải pháp thanh toán đóng hộp).
Theo một nghĩa nào đó, đây là một dự án lịch sử đối với thị trường Nga. Nó có thể được so sánh với những gì được mô tả trong cuốn sách “Tháng thần thoại” của Frederick Brooks. Sau đó, vào những năm 60, IBM đã thuê 360 người để phát triển hệ điều hành OS/5 mới cho máy tính lớn. Chúng tôi có ít hơn - 000, nhưng chúng tôi có sẵn và tính đến việc sử dụng nguồn mở và các phương pháp tiếp cận mới, chúng tôi làm việc hiệu quả hơn.
Dưới đây là các lĩnh vực thanh toán hay nói rộng hơn là hệ thống kinh doanh. Mọi người từ doanh nghiệp biết rất rõ về CRM. Mọi người chắc hẳn đã có sẵn các hệ thống khác: Open API, API Gateway.
Mở API
Hãy xem lại các con số và cách Open API hiện đang hoạt động. Tải của nó là 10 giao dịch mỗi giây. Vì chúng tôi có kế hoạch tích cực phát triển lớp dịch vụ vi mô và xây dựng API công khai MegaFon, nên chúng tôi kỳ vọng phần này sẽ có sự phát triển lớn hơn trong tương lai. Chắc chắn sẽ có 100 giao dịch.
Tôi không biết liệu chúng ta có thể so sánh với Mail.ru về SSO hay không - những người này dường như có 1 giao dịch mỗi giây. Giải pháp của họ cực kỳ thú vị đối với chúng tôi và chúng tôi dự định áp dụng kinh nghiệm của họ - ví dụ: tạo bản sao lưu SSO chức năng bằng Tarantool. Hiện các nhà phát triển từ Mail.ru đang làm việc này cho chúng tôi.
CRM
CRM cũng chính là 80 triệu người đăng ký mà chúng tôi muốn tăng lên một tỷ, vì đã có 300 triệu tài liệu bao gồm lịch sử ba năm. Chúng tôi thực sự mong đợi các dịch vụ mới và ở đây điểm tăng trưởng là dịch vụ kết nối. Đây là một quả bóng sẽ phát triển vì ngày càng có nhiều dịch vụ hơn. Theo đó, chúng ta sẽ cần một câu chuyện, chúng ta không muốn vấp phải điều này.
Tự thanh toán về việc xuất hóa đơn, làm việc với các khoản phải thu của khách hàng chuyển đổi thành một miền riêng. Để cải thiện hiệu suất, mô hình kiến trúc kiến trúc miền ứng dụng.
Hệ thống được chia thành các miền, tải được phân phối và khả năng chịu lỗi được đảm bảo. Ngoài ra, chúng tôi đã làm việc với kiến trúc phân tán.
Mọi thứ khác đều là giải pháp cấp doanh nghiệp. Trong bộ nhớ cuộc gọi - 2 tỷ mỗi ngày, 60 tỷ/tháng. Đôi khi bạn phải đếm chúng trong một tháng, và sẽ tốt hơn nếu nhanh chóng. Giám sát tài chính - đây chính xác là 300 triệu không ngừng tăng trưởng: thuê bao thường xuyên chạy giữa các nhà khai thác, làm tăng phần này.
Thành phần viễn thông nhất của thông tin di động là thanh toán trực tuyến. Đây là những hệ thống cho phép bạn gọi hoặc không gọi, đưa ra quyết định theo thời gian thực. Ở đây tải là 30 giao dịch mỗi giây, nhưng có tính đến sự tăng trưởng trong truyền dữ liệu, chúng tôi dự định 250 giao dịch, và do đó chúng tôi rất quan tâm đến Tarantool.
Hình ảnh trước là các miền mà chúng ta sẽ sử dụng Tarantool. Tất nhiên, bản thân CRM rộng hơn và chúng tôi sẽ sử dụng nó trong phần cốt lõi.
Con số TTX ước tính của chúng tôi là 100 triệu người đăng ký khiến tôi với tư cách là một kiến trúc sư bối rối - nếu 101 triệu thì sao? Bạn có phải làm lại mọi thứ một lần nữa không? Để ngăn điều này xảy ra, chúng tôi sử dụng bộ nhớ đệm, đồng thời tăng khả năng truy cập.
Nói chung, có hai cách sử dụng Tarantool. Đầu tiên - xây dựng tất cả bộ nhớ đệm ở cấp độ vi dịch vụ. Theo như tôi hiểu thì VimpelCom đang đi theo con đường này, tạo bộ đệm cho các máy khách.
Chúng tôi ít phụ thuộc hơn vào các nhà cung cấp, chúng tôi đang thay đổi lõi BSS, vì vậy chúng tôi có sẵn một tệp khách hàng duy nhất. Nhưng chúng tôi muốn mở rộng nó. Do đó, chúng tôi thực hiện một cách tiếp cận hơi khác - tạo bộ nhớ đệm bên trong hệ thống.
Bằng cách này, sẽ có ít sự đồng bộ hóa hơn - một hệ thống chịu trách nhiệm về cả bộ đệm và nguồn chính.
Phương pháp này rất phù hợp với cách tiếp cận Tarantool với khung giao dịch, khi chỉ những phần liên quan đến cập nhật, tức là thay đổi dữ liệu, mới được cập nhật. Mọi thứ khác có thể được lưu trữ ở một nơi khác. Không có hồ dữ liệu khổng lồ, bộ đệm toàn cầu không được quản lý. Bộ nhớ đệm được thiết kế cho hệ thống, cho sản phẩm, hoặc cho khách hàng hoặc để giúp việc bảo trì dễ dàng hơn. Khi một thuê bao gọi đến và không hài lòng về chất lượng dịch vụ của bạn, bạn muốn cung cấp dịch vụ có chất lượng.
RTO và RPO
Có hai thuật ngữ trong CNTT - RTO и RPO.
Mục tiêu thời gian phục hồi là thời gian cần thiết để khôi phục lại dịch vụ sau khi có sự cố. RTO = 0 có nghĩa là ngay cả khi có sự cố xảy ra, dịch vụ vẫn tiếp tục hoạt động.
Mục tiêu điểm phục hồi - đây là thời gian khôi phục dữ liệu, chúng ta có thể mất bao nhiêu dữ liệu trong một khoảng thời gian nhất định. RPO = 0 có nghĩa là chúng tôi không bị mất dữ liệu.
Nhiệm vụ Tarantool
Hãy thử giải quyết vấn đề cho Tarantool.
Được cho: một giỏ ứng dụng mà mọi người đều hiểu, chẳng hạn như ở Amazon hoặc nơi nào khác. cần thiết để giỏ hàng hoạt động 24 giờ, 7 ngày một tuần, hoặc 99,99% thời gian. Các đơn hàng đến với chúng tôi phải được giữ nguyên theo thứ tự, vì chúng tôi không thể bật hoặc tắt ngẫu nhiên kết nối thuê bao - mọi thứ phải nhất quán nghiêm ngặt. Đăng ký trước sẽ ảnh hưởng đến đăng ký tiếp theo, vì vậy dữ liệu rất quan trọng - không được thiếu dữ liệu nào.
phán quyết. Bạn có thể cố gắng giải quyết trực tiếp và hỏi các nhà phát triển cơ sở dữ liệu, nhưng vấn đề không thể được giải quyết bằng toán học. Bạn có thể nhớ các định lý, định luật bảo toàn, vật lý lượng tử, nhưng tại sao - nó không thể giải được ở cấp độ DB.
Cách tiếp cận kiến trúc cũ hiệu quả ở đây - bạn cần hiểu rõ về chủ đề và sử dụng nó để giải câu đố này.
Giải pháp của chúng tôi: tạo sổ đăng ký phân tán các ứng dụng trên Tarantool - cụm phân phối theo địa lý. Trong sơ đồ, đây là ba trung tâm xử lý dữ liệu khác nhau - hai trung tâm trước Urals, một ngoài Urals và chúng tôi phân phối tất cả các yêu cầu giữa các trung tâm này.
Netflix, hiện được coi là một trong những công ty dẫn đầu về CNTT, chỉ có một trung tâm dữ liệu cho đến năm 2012. Vào đêm trước lễ Giáng sinh của Công giáo, ngày 24 tháng XNUMX, trung tâm dữ liệu này đã ngừng hoạt động. Người dùng ở Canada và Hoa Kỳ không có bộ phim yêu thích của họ, rất khó chịu và viết về nó trên mạng xã hội. Netflix hiện có ba trung tâm dữ liệu ở bờ biển phía Tây-Đông và một ở Tây Âu.
Ban đầu, chúng tôi đang xây dựng một giải pháp phân phối theo địa lý - khả năng chịu lỗi rất quan trọng đối với chúng tôi.
Vậy là chúng ta có một cụm, nhưng còn RPO = 0 và RTO = 0 thì sao? Giải pháp rất đơn giản, tùy thuộc vào chủ đề.
Điều gì là quan trọng trong các ứng dụng? Hai phần: Ném rổ ĐẾN đưa ra quyết định mua hàng và SAU. Phần DO trong viễn thông thường được gọi là nắm bắt đơn hàng hoặc đàm phán đơn hàng. Trong viễn thông, điều này có thể khó khăn hơn nhiều so với trong cửa hàng trực tuyến, vì ở đó khách hàng phải được phục vụ, đưa ra 5 lựa chọn và tất cả điều này diễn ra trong một thời gian nhưng giỏ đã đầy. Tại thời điểm này, lỗi có thể xảy ra nhưng không đáng sợ vì nó diễn ra tương tác dưới sự giám sát của con người.
Nếu trung tâm dữ liệu Moscow đột nhiên gặp sự cố thì bằng cách tự động chuyển sang trung tâm dữ liệu khác, chúng tôi sẽ tiếp tục làm việc. Về mặt lý thuyết, một sản phẩm có thể bị mất trong giỏ hàng, nhưng bạn nhìn thấy nó, thêm lại vào giỏ hàng và tiếp tục làm việc. Trong trường hợp này RTO = 0.
Đồng thời, có một tùy chọn thứ hai: khi chúng tôi nhấp vào “gửi”, chúng tôi muốn dữ liệu không bị mất. Kể từ thời điểm này, quá trình tự động hóa bắt đầu hoạt động - đây là RPO = 0. Sử dụng hai mẫu khác nhau này, trong một trường hợp, nó có thể chỉ đơn giản là một cụm được phân phối theo địa lý với một bản chính có thể chuyển đổi, trong trường hợp khác là một loại bản ghi đại biểu nào đó. Các mẫu có thể khác nhau, nhưng chúng tôi giải quyết được vấn đề.
Hơn nữa, nhờ có sổ đăng ký ứng dụng được phân phối, chúng tôi cũng có thể mở rộng quy mô tất cả - có nhiều người điều phối và người thực thi truy cập vào sổ đăng ký này.
Cassandra và Tarantool cùng nhau
Còn có một trường hợp khác - "trình bày số dư". Đây là một trường hợp thú vị về việc sử dụng chung Cassandra và Tarantool.
Chúng tôi sử dụng Cassandra vì 2 tỷ cuộc gọi mỗi ngày không phải là giới hạn và sẽ còn nhiều hơn nữa. Các nhà tiếp thị thích tô màu lưu lượng truy cập theo nguồn; chẳng hạn, ngày càng có nhiều chi tiết xuất hiện trên mạng xã hội. Tất cả đều thêm vào câu chuyện.
Cassandra cho phép bạn chia tỷ lệ theo chiều ngang theo bất kỳ kích thước nào.
Chúng tôi cảm thấy thoải mái với Cassandra, nhưng nó có một vấn đề - nó đọc không tốt. Mọi thứ đều ổn khi ghi âm, 30 mỗi giây không phải là vấn đề - vấn đề đọc.
Do đó, một chủ đề về bộ đệm đã xuất hiện, đồng thời chúng tôi đã giải quyết được vấn đề sau: có một trường hợp truyền thống cũ khi thiết bị chuyển từ thanh toán trực tuyến đi vào các tệp mà chúng tôi tải vào Cassandra. Chúng tôi đã phải vật lộn với vấn đề tải xuống các tệp này một cách đáng tin cậy, thậm chí sử dụng lời khuyên về truyền tệp của trình quản lý IBM - có những giải pháp quản lý việc truyền tệp hiệu quả, chẳng hạn như sử dụng giao thức UDP thay vì TCP. Điều này tốt, nhưng vẫn còn vài phút và chúng tôi vẫn chưa tải hết, nhân viên điều hành ở trung tâm cuộc gọi không thể trả lời khách hàng chuyện gì đã xảy ra với số dư của anh ấy - chúng tôi phải đợi.
Để ngăn chặn điều này xảy ra, chúng tôi chúng tôi sử dụng dự trữ chức năng song song. Ví dụ: khi chúng tôi gửi một sự kiện qua Kafka tới Tarantool, tính toán lại tổng hợp theo thời gian thực cho ngày hôm nay, chúng tôi nhận được số dư tiền mặt, có thể chuyển số dư ở bất kỳ tốc độ nào, ví dụ: 100 nghìn giao dịch mỗi giây và 2 giây tương tự.
Mục tiêu là sau khi thực hiện cuộc gọi, trong vòng 2 giây trong tài khoản cá nhân của bạn sẽ không chỉ có số dư thay đổi mà còn có thông tin về lý do số dư thay đổi.
Kết luận
Đây là những ví dụ về việc sử dụng Tarantool. Chúng tôi thực sự thích tính cởi mở của Mail.ru và sự sẵn sàng xem xét các trường hợp khác nhau của họ.
Rất khó để các nhà tư vấn từ BCG hay McKinsey, Accenture hay IBM có thể làm chúng tôi ngạc nhiên bằng điều gì đó mới mẻ - phần lớn những gì họ cung cấp thì chúng tôi đã làm, đã làm hoặc đang dự định làm. Tôi nghĩ rằng Tarantool sẽ chiếm vị trí xứng đáng trong kho công nghệ của chúng tôi và sẽ thay thế nhiều công nghệ hiện có. Chúng tôi đang trong giai đoạn tích cực phát triển dự án này.
Báo cáo của Oleg và Andrey là một trong những báo cáo hay nhất tại Hội nghị Tarantool năm ngoái và vào ngày 17 tháng XNUMX, Oleg Ivlev sẽ phát biểu tại với một báo cáo . Alexander Deulin cũng sẽ có bài thuyết trình từ MegaFon . Hãy cùng tìm hiểu những gì đã thay đổi, những kế hoạch nào đã được thực hiện. Tham gia - hội nghị miễn phí, tất cả những gì bạn phải làm là ... Mọi thứ và chương trình hội nghị đã được hình thành: các trường hợp mới, trải nghiệm mới trong việc sử dụng Tarantool, kiến trúc, doanh nghiệp, hướng dẫn và dịch vụ vi mô.
Nguồn: www.habr.com