Sự phát triển của kiến ​​trúc hệ thống giao dịch và thanh toán bù trừ của Sở giao dịch Moscow. Phần 1

Chào mọi người! Tên tôi là Sergey Kostanbaev, tại Sàn giao dịch, tôi đang phát triển cốt lõi của hệ thống giao dịch.

Khi các bộ phim Hollywood chiếu Sàn giao dịch chứng khoán New York, nó luôn trông như thế này: đám đông người, mọi người đang la hét điều gì đó, vẫy giấy tờ, sự hỗn loạn hoàn toàn đang diễn ra. Điều này chưa bao giờ xảy ra ở đây trên Sở giao dịch Moscow, vì giao dịch đã được tiến hành điện tử ngay từ đầu và dựa trên hai nền tảng chính - Spectra (thị trường ngoại hối) và ASTS (thị trường ngoại hối, chứng khoán và tiền tệ). Và hôm nay tôi muốn nói về sự phát triển của kiến ​​trúc hệ thống giao dịch và thanh toán bù trừ ASTS, về các giải pháp và phát hiện khác nhau. Truyện sẽ dài nên mình phải chia làm XNUMX phần.

Chúng tôi là một trong số ít sàn giao dịch trên thế giới giao dịch tài sản thuộc mọi loại và cung cấp đầy đủ các dịch vụ trao đổi. Ví dụ, năm ngoái chúng tôi đứng thứ hai trên thế giới về khối lượng giao dịch trái phiếu, vị trí thứ 25 trong số tất cả các sàn giao dịch chứng khoán, vị trí thứ 13 về vốn hóa trên các sàn giao dịch đại chúng.

Đối với những người tham gia giao dịch chuyên nghiệp, các thông số như thời gian phản hồi, độ ổn định của phân phối thời gian (jitter) và độ tin cậy của toàn bộ tổ hợp là rất quan trọng. Chúng tôi hiện xử lý hàng chục triệu giao dịch mỗi ngày. Quá trình xử lý mỗi giao dịch của nhân hệ thống mất hàng chục micro giây. Tất nhiên, các nhà khai thác di động trong đêm giao thừa hay bản thân các công cụ tìm kiếm có khối lượng công việc cao hơn chúng tôi, nhưng xét về khối lượng công việc, cộng với những đặc điểm nêu trên, ít ai có thể so sánh được với chúng tôi, theo tôi. Đồng thời, điều quan trọng đối với chúng tôi là hệ thống không bị chậm đi một giây nào, hoạt động hoàn toàn ổn định và tất cả người dùng đều bình đẳng.

Một ít lịch sử

Năm 1994, hệ thống ASTS của Úc được ra mắt trên Sàn giao dịch tiền tệ liên ngân hàng Moscow (MICEX), và kể từ thời điểm đó, lịch sử giao dịch điện tử của Nga có thể được tính đến. Năm 1998, kiến ​​trúc sàn giao dịch đã được hiện đại hóa để giới thiệu giao dịch qua Internet. Kể từ đó, tốc độ triển khai các giải pháp mới và thay đổi kiến ​​trúc trong tất cả các hệ thống và hệ thống con ngày càng tăng.

Trong những năm đó, hệ thống trao đổi hoạt động trên phần cứng cao cấp - máy chủ HP Superdome 9000 cực kỳ đáng tin cậy (được xây dựng trên PA-RISC), trong đó mọi thứ đều được sao chép hoàn toàn: hệ thống con đầu vào/đầu ra, mạng, RAM (trên thực tế, có một mảng RAM RAID), bộ xử lý (có thể hoán đổi nóng). Có thể thay đổi bất kỳ thành phần máy chủ nào mà không cần dừng máy. Chúng tôi đã dựa vào những thiết bị này và coi chúng hầu như không an toàn. Hệ điều hành là hệ thống HP UX giống Unix.

Nhưng kể từ khoảng năm 2010, một hiện tượng đã xuất hiện được gọi là giao dịch tần số cao (HFT), hay giao dịch tần suất cao - nói một cách đơn giản là robot giao dịch chứng khoán. Chỉ trong 2,5 năm, tải trên máy chủ của chúng tôi đã tăng 140 lần.

Không thể chịu được tải trọng như vậy với kiến ​​trúc và thiết bị cũ. Nó là cần thiết để thích nghi bằng cách nào đó.

bắt đầu

Các yêu cầu tới hệ thống trao đổi có thể được chia thành hai loại:

• Giao dịch. Nếu bạn muốn mua đô la, cổ phiếu hoặc thứ gì khác, bạn gửi giao dịch đến hệ thống giao dịch và nhận được phản hồi thành công.
• Yêu cầu thông tin. Nếu bạn muốn tìm hiểu giá hiện tại, hãy xem sổ lệnh hoặc chỉ số, sau đó gửi yêu cầu thông tin.

Về mặt sơ đồ, cốt lõi của hệ thống có thể được chia thành ba cấp độ:

• Cấp độ khách hàng, tại đó các nhà môi giới và khách hàng làm việc. Tất cả đều tương tác với các máy chủ truy cập.
• Máy chủ cổng là máy chủ lưu đệm xử lý cục bộ tất cả các yêu cầu thông tin. Bạn có muốn biết cổ phiếu Sberbank hiện đang giao dịch ở mức giá nào không? Yêu cầu đi đến máy chủ truy cập.
• Nhưng nếu bạn muốn mua cổ phiếu thì yêu cầu sẽ được chuyển đến máy chủ trung tâm (Trade Engine). Có một máy chủ như vậy cho từng loại thị trường, chúng đóng một vai trò quan trọng, chính vì chúng mà chúng tôi đã tạo ra hệ thống này.

Cốt lõi của hệ thống giao dịch là cơ sở dữ liệu trong bộ nhớ thông minh, trong đó tất cả các giao dịch đều là giao dịch trao đổi. Cơ sở được viết bằng C, phần phụ thuộc bên ngoài duy nhất là thư viện libc và không có phân bổ bộ nhớ động nào cả. Để giảm thời gian xử lý, hệ thống bắt đầu với một tập hợp mảng tĩnh và di chuyển dữ liệu tĩnh: đầu tiên, tất cả dữ liệu cho ngày hiện tại được tải vào bộ nhớ và không thực hiện truy cập đĩa nào nữa, mọi công việc chỉ được thực hiện trong bộ nhớ. Khi hệ thống khởi động, tất cả dữ liệu tham chiếu đã được sắp xếp nên việc tìm kiếm hoạt động rất hiệu quả và tốn ít thời gian trong thời gian chạy. Tất cả các bảng đều được tạo bằng danh sách và cây xâm nhập cho cấu trúc dữ liệu động để chúng không yêu cầu cấp phát bộ nhớ khi chạy.

Chúng ta hãy điểm qua ngắn gọn về lịch sử phát triển hệ thống giao dịch và thanh toán bù trừ của chúng tôi.
Phiên bản đầu tiên của kiến ​​trúc hệ thống giao dịch và thanh toán bù trừ được xây dựng trên cái gọi là tương tác Unix: bộ nhớ dùng chung, các ngữ nghĩa và hàng đợi được sử dụng và mỗi quy trình bao gồm một luồng duy nhất. Cách tiếp cận này phổ biến vào đầu những năm 1990.

Phiên bản đầu tiên của hệ thống có hai cấp độ Cổng và một máy chủ trung tâm của hệ thống giao dịch. Quy trình làm việc như thế này:

• Máy khách gửi yêu cầu đến Cổng. Nó kiểm tra tính hợp lệ của định dạng (chứ không phải bản thân dữ liệu) và từ chối các giao dịch không chính xác.
• Nếu một yêu cầu thông tin đã được gửi đi, nó sẽ được thực thi cục bộ; nếu chúng ta đang nói về một giao dịch thì nó sẽ được chuyển hướng đến máy chủ trung tâm.
• Sau đó, công cụ giao dịch sẽ xử lý giao dịch, sửa đổi bộ nhớ cục bộ và gửi phản hồi đến giao dịch cũng như chính giao dịch đó để sao chép bằng cách sử dụng một công cụ sao chép riêng biệt.
• Cổng nhận phản hồi từ nút trung tâm và chuyển tiếp nó đến máy khách.
• Sau một thời gian, Gateway nhận giao dịch thông qua cơ chế sao chép và lần này nó thực thi giao dịch cục bộ, thay đổi cấu trúc dữ liệu để các yêu cầu thông tin tiếp theo hiển thị dữ liệu mới nhất.

Trên thực tế, nó mô tả một mô hình sao chép trong đó Cổng sao chép hoàn toàn các hành động được thực hiện trong hệ thống giao dịch. Một kênh sao chép riêng biệt đảm bảo rằng các giao dịch được thực hiện theo cùng thứ tự trên nhiều nút truy cập.

Vì mã là đơn luồng nên một sơ đồ cổ điển với các nhánh quy trình đã được sử dụng để phục vụ nhiều khách hàng. Tuy nhiên, việc phân nhánh toàn bộ cơ sở dữ liệu rất tốn kém, do đó, các quy trình dịch vụ nhẹ đã được sử dụng để thu thập các gói từ các phiên TCP và chuyển chúng vào một hàng đợi (Hàng đợi tin nhắn SystemV). Gateway và Trade Engine chỉ hoạt động với hàng đợi này, thực hiện các giao dịch từ đó để thực hiện. Không thể gửi phản hồi tới nó nữa vì không rõ quy trình dịch vụ nào sẽ đọc nó. Vì vậy, chúng tôi đã sử dụng một mẹo: mỗi quy trình phân nhánh sẽ tạo ra một hàng đợi phản hồi cho chính nó và khi một yêu cầu đến hàng đợi đến, một thẻ cho hàng đợi phản hồi sẽ ngay lập tức được thêm vào đó.

Việc liên tục sao chép một lượng lớn dữ liệu từ hàng đợi này sang hàng đợi khác đã tạo ra các vấn đề, đặc biệt là đối với các yêu cầu thông tin. Do đó, chúng tôi đã sử dụng một thủ thuật khác: ngoài hàng đợi phản hồi, mỗi tiến trình còn tạo bộ nhớ dùng chung (SystemV Shared Memory). Bản thân các gói đã được đặt trong đó và chỉ một thẻ được lưu trong hàng đợi, cho phép một người tìm thấy gói gốc. Điều này giúp lưu trữ dữ liệu trong bộ đệm của bộ xử lý.

SystemV IPC bao gồm các tiện ích để xem trạng thái của hàng đợi, bộ nhớ và các đối tượng semaphore. Chúng tôi chủ động sử dụng thông tin này để hiểu điều gì đang xảy ra trong hệ thống tại một thời điểm cụ thể, nơi các gói được tích lũy, điều gì đã bị chặn, v.v.

Nâng cấp đầu tiên

Trước hết, chúng tôi đã loại bỏ Cổng quy trình đơn. Hạn chế đáng kể của nó là nó có thể xử lý một giao dịch sao chép hoặc một yêu cầu thông tin từ khách hàng. Và khi tải tăng lên, Gateway sẽ mất nhiều thời gian hơn để xử lý yêu cầu và sẽ không thể xử lý luồng sao chép. Ngoài ra, nếu khách hàng đã gửi giao dịch thì bạn chỉ cần kiểm tra tính hợp lệ của giao dịch đó và chuyển tiếp thêm. Do đó, chúng tôi đã thay thế quy trình Cổng đơn bằng nhiều thành phần có thể chạy song song: thông tin đa luồng và quy trình giao dịch chạy độc lập với nhau trên vùng bộ nhớ dùng chung bằng cách sử dụng khóa RW. Đồng thời, chúng tôi đã giới thiệu các quy trình điều phối và sao chép.

Tác động của giao dịch tần số cao

Phiên bản kiến ​​trúc trên tồn tại cho đến năm 2010. Trong khi đó, chúng tôi không còn hài lòng với hiệu suất của máy chủ HP Superdome. Ngoài ra, kiến ​​trúc PA-RISC gần như đã chết; nhà cung cấp không cung cấp bất kỳ bản cập nhật quan trọng nào. Kết quả là chúng tôi bắt đầu chuyển từ HP UX/PA RISC sang Linux/x86. Quá trình chuyển đổi bắt đầu với việc điều chỉnh các máy chủ truy cập.

Tại sao chúng ta lại phải thay đổi kiến ​​trúc? Thực tế là giao dịch tần số cao đã thay đổi đáng kể cấu hình tải trên lõi hệ thống.

Giả sử chúng ta có một giao dịch nhỏ gây ra sự thay đổi giá đáng kể - ai đó đã mua nửa tỷ đô la. Sau vài mili giây, tất cả những người tham gia thị trường đều nhận thấy điều này và bắt đầu điều chỉnh. Đương nhiên, các yêu cầu xếp thành một hàng đợi khổng lồ mà hệ thống sẽ mất nhiều thời gian để xử lý.

Ở khoảng thời gian 50 ms này, tốc độ trung bình là khoảng 16 nghìn giao dịch mỗi giây. Nếu giảm thời lượng cửa sổ xuống 20 mili giây, chúng tôi sẽ đạt được tốc độ trung bình là 90 nghìn giao dịch mỗi giây, với mức cao nhất là 200 nghìn giao dịch. Nói cách khác, tải không cố định, có thể xảy ra đột ngột. Và hàng đợi yêu cầu luôn phải được xử lý nhanh chóng.

Nhưng tại sao lại có hàng đợi? Vì vậy, trong ví dụ của chúng tôi, nhiều người dùng nhận thấy sự thay đổi giá và gửi giao dịch tương ứng. Họ đến Gateway, nó sắp xếp chúng theo thứ tự, đặt ra một thứ tự nhất định và gửi chúng lên mạng. Bộ định tuyến xáo trộn các gói và chuyển tiếp chúng. Gói hàng của ai đến trước thì giao dịch đó “thắng”. Do đó, khách hàng của sàn giao dịch bắt đầu nhận thấy rằng nếu cùng một giao dịch được gửi từ nhiều Cổng thì khả năng xử lý nhanh chóng của giao dịch đó sẽ tăng lên. Chẳng bao lâu, các robot trao đổi bắt đầu tấn công Gateway với các yêu cầu và hàng loạt giao dịch xuất hiện.

Một vòng tiến hóa mới

Sau khi thử nghiệm và nghiên cứu sâu rộng, chúng tôi đã chuyển sang nhân hệ điều hành thời gian thực. Để làm điều này, chúng tôi đã chọn RedHat Enterprise MRG Linux, trong đó MRG là viết tắt của lưới nhắn tin thời gian thực. Ưu điểm của các bản vá thời gian thực là chúng tối ưu hóa hệ thống để thực thi nhanh nhất có thể: tất cả các quy trình được xếp theo hàng đợi FIFO, các lõi có thể được cách ly, không bị đẩy ra ngoài, tất cả các giao dịch đều được xử lý theo trình tự nghiêm ngặt.

Màu đỏ - làm việc với hàng đợi trong kernel thông thường, màu xanh lá cây - hoạt động trong kernel thời gian thực.

Nhưng để đạt được độ trễ thấp trên các máy chủ thông thường không phải là điều dễ dàng:

• Chế độ SMI, trong kiến ​​trúc x86 là cơ sở để làm việc với các thiết bị ngoại vi quan trọng, gây nhiễu rất nhiều. Việc xử lý tất cả các loại sự kiện phần cứng cũng như quản lý các thành phần và thiết bị được thực hiện bởi phần sụn ở chế độ được gọi là chế độ SMI trong suốt, trong đó hệ điều hành hoàn toàn không nhìn thấy phần sụn đang làm gì. Theo quy định, tất cả các nhà cung cấp lớn đều cung cấp các tiện ích mở rộng đặc biệt cho máy chủ phần sụn cho phép giảm lượng xử lý SMI.
• Không nên có sự kiểm soát động tần số bộ xử lý, điều này dẫn đến thời gian ngừng hoạt động bổ sung.
• Khi nhật ký hệ thống tệp bị xóa, một số quy trình nhất định sẽ xảy ra trong kernel gây ra sự chậm trễ không thể đoán trước.
• Bạn cần chú ý đến những thứ như CPU ​​Affinity, Interrupt ái lực, NUMA.

Tôi phải nói rằng chủ đề thiết lập phần cứng và kernel Linux để xử lý thời gian thực xứng đáng có một bài viết riêng. Chúng tôi đã dành rất nhiều thời gian thử nghiệm và nghiên cứu trước khi đạt được kết quả tốt.

Khi chuyển từ máy chủ PA-RISC sang x86, thực tế chúng tôi không phải thay đổi mã hệ thống nhiều mà chỉ điều chỉnh và cấu hình lại nó. Đồng thời, chúng tôi đã sửa một số lỗi. Ví dụ: hậu quả của việc PA RISC là hệ thống Big endian và x86 là hệ thống Little endian nhanh chóng xuất hiện: ví dụ: dữ liệu được đọc không chính xác. Lỗi phức tạp hơn là PA RISC sử dụng nhất quán nhất quán (Tuần tự nhất quán) truy cập bộ nhớ, trong khi x86 có thể sắp xếp lại các hoạt động đọc, do đó mã hoàn toàn hợp lệ trên một nền tảng lại bị hỏng trên nền tảng khác.

Sau khi chuyển sang x86, hiệu suất tăng gần gấp ba lần, thời gian xử lý giao dịch trung bình giảm xuống còn 60 μs.

Bây giờ chúng ta hãy xem xét kỹ hơn những thay đổi quan trọng nào đã được thực hiện đối với kiến ​​trúc hệ thống.

Sử thi dự trữ nóng

Khi chuyển sang máy chủ thông thường, chúng tôi nhận thấy rằng chúng kém tin cậy hơn. Do đó, khi tạo một kiến ​​trúc mới, chúng tôi tiên nghiệm giả định khả năng xảy ra lỗi của một hoặc nhiều nút. Vì vậy, cần có một hệ thống dự phòng nóng có thể nhanh chóng chuyển sang các máy dự phòng.

Ngoài ra còn có các yêu cầu khác:

• Trong mọi trường hợp, bạn không nên mất các giao dịch đã xử lý.
• Hệ thống phải tuyệt đối minh bạch đối với cơ sở hạ tầng của chúng tôi.
• Khách hàng sẽ không thấy kết nối bị mất.
• Việc đặt trước không được gây ra sự chậm trễ đáng kể vì đây là yếu tố quan trọng đối với việc trao đổi.

Khi tạo hệ thống dự phòng nóng, chúng tôi không coi các tình huống đó là lỗi kép (ví dụ: mạng trên một máy chủ ngừng hoạt động và máy chủ chính bị treo); không xem xét đến khả năng xảy ra lỗi trong phần mềm do chúng được phát hiện trong quá trình thử nghiệm; và không xem xét hoạt động không chính xác của phần cứng.

Kết quả là chúng tôi đã đi đến sơ đồ sau:

• Máy chủ chính tương tác trực tiếp với máy chủ Gateway.
• Tất cả các giao dịch nhận được trên máy chủ chính sẽ được sao chép ngay lập tức sang máy chủ dự phòng thông qua một kênh riêng. Trọng tài (Thống đốc) điều phối việc chuyển đổi nếu có vấn đề phát sinh.

  

• Máy chủ chính xử lý từng giao dịch và chờ xác nhận từ máy chủ dự phòng. Để giữ độ trễ ở mức tối thiểu, chúng tôi tránh chờ giao dịch hoàn tất trên máy chủ dự phòng. Vì thời gian để một giao dịch di chuyển trên mạng tương đương với thời gian thực hiện nên không có độ trễ bổ sung nào được thêm vào.
• Chúng tôi chỉ có thể kiểm tra trạng thái xử lý của máy chủ chính và máy chủ dự phòng cho giao dịch trước đó và không xác định được trạng thái xử lý của giao dịch hiện tại. Vì chúng tôi vẫn đang sử dụng các quy trình đơn luồng nên việc chờ phản hồi từ Sao lưu sẽ làm chậm toàn bộ quy trình xử lý, vì vậy, chúng tôi đã đưa ra một thỏa hiệp hợp lý: chúng tôi đã kiểm tra kết quả của giao dịch trước đó.

Đề án đã hoạt động như sau.

Giả sử máy chủ chính ngừng phản hồi nhưng Cổng vẫn tiếp tục liên lạc. Máy chủ dự phòng xảy ra thời gian chờ, nó liên hệ với Thống đốc, người chỉ định cho nó vai trò máy chủ chính và tất cả các Cổng chuyển sang máy chủ chính mới.

Nếu máy chủ chính trực tuyến trở lại, điều này cũng gây ra thời gian chờ nội bộ vì không có cuộc gọi nào đến máy chủ từ Cổng trong một thời gian nhất định. Sau đó, anh ta cũng quay sang Thống đốc và loại anh ta ra khỏi kế hoạch. Do đó, sàn giao dịch hoạt động với một máy chủ cho đến hết thời gian giao dịch. Vì xác suất xảy ra lỗi máy chủ là khá thấp nên sơ đồ này được coi là khá chấp nhận được; nó không chứa logic phức tạp và dễ kiểm tra.

Tiếp tục.

Nguồn: www.habr.com