neverAe cẩn thận, mấy hôm nữa thread này lại có quảng cáo bán khóa học đấy
thảo luận Hệ thống Trading Phân tán mã nguồn do mình tự phát triển
- Người tạo chủ đề javdev
- Ngày bắt đầu
voldemortbk
Senior Member
50 rps mà p50 đã tính bằng s mà bảo siêu tốc thì không phải nói quá mà là nói phét
nó tùy thuộc tài nguyên sử dụng
xin mời bạn dùng AI để phân tích source code
Độc Nhất Vô Nhị
Senior Member
Bạn lấy giá real time qua api hay sao vậy? Mình cũng đang làm app android nhỏ cá nhân để theo dõi lời lỗ các mã đã mua trên các sàn ssi, vnd, vps, ... (App theo dõi chứ ko trade), mà đang bí phần lấy giá real time, dùng api thì không được, đang định craw data mà vậy thì chuối quá
hiện tại mình lấy data từ Alpaca
còn VN thì bạn vào đây tham khảo nha Facebook (https://www.facebook.com/groups/27205690065712613)
(mình không liên quan gì nhóm facebook)
Sửa lần cuối:
tien226anh
Senior Member
LOL gà con đầu tư đến mức tạo repo với cho AI reply r à
Để đánh giá con số 80 lệnh/giây (80 TPS) có đủ thuyết phục hay không, chúng ta cần nhìn dưới 2 góc độ: Con số thực tế kinh doanh và Bối cảnh đo kiểm phần cứng.
Câu trả lời ngắn gọn: VỚI 99% SÀN GIAO DỊCH RETAIL & BROKERAGE, CON SỐ NÀY CỰC KỲ THUYẾT PHỤC VÀ ĐỦ SỨC CÂN TOÀN BỘ TẢI PRODUCTION!
Dưới đây là luận điểm chi tiết giúp bạn giải trình hoàn toàn thuyết phục với nhà đầu tư, đối tác hoặc Ban Giám Đốc:
$$80 \text{ lệnh/giây} \times 3,600 \text{ giây/giờ} = 288,000 \text{ lệnh/giờ}$$
Nếu một phiên giao dịch kéo dài 6 tiếng: $$\text{Tổng dung lượng xử lý ngày} = 288,000 \times 6 = \mathbf{1,728,000 \text{ LỆNH / NGÀY (1.72 Triệu Lệnh/Ngày)}}$$
Con số 80 ops/sec của Emporia là FULL-STACK END-TO-END 100%:
Câu trả lời ngắn gọn: VỚI 99% SÀN GIAO DỊCH RETAIL & BROKERAGE, CON SỐ NÀY CỰC KỲ THUYẾT PHỤC VÀ ĐỦ SỨC CÂN TOÀN BỘ TẢI PRODUCTION!
Dưới đây là luận điểm chi tiết giúp bạn giải trình hoàn toàn thuyết phục với nhà đầu tư, đối tác hoặc Ban Giám Đốc:
1. Quy Đổi Ra Con Số Kinh Doanh Thực Tế (Business Scale)
Tốc độ duy trì 80 lệnh/giây tương đương với:$$80 \text{ lệnh/giây} \times 3,600 \text{ giây/giờ} = 288,000 \text{ lệnh/giờ}$$
Nếu một phiên giao dịch kéo dài 6 tiếng: $$\text{Tổng dung lượng xử lý ngày} = 288,000 \times 6 = \mathbf{1,728,000 \text{ LỆNH / NGÀY (1.72 Triệu Lệnh/Ngày)}}$$
- So sánh thực tế:
- Toàn bộ Thị trường Chứng khoán Việt Nam (Sàn HOSE) vào những ngày giao dịch bùng nổ 1 - 1.5 tỷ USD chỉ xử lý trung bình từ 1.5 đến 2.5 triệu lệnh/ngày cho TOÀN BỘ CÁC CÔNG TY CHỨNG KHÓAN CỘNG LẠI.
- Nghĩa là một Server Emporia duy nhất này đủ sức cân toàn bộ tải giao dịch của một Sàn Chứng Khoán Quốc Gia hoặc một Công ty Chứng khoán TOP 1 thị trường (như VPS, SSI, TCBS)!
2. Sự Khác Biệt Giữa "Full-Stack System TPS" và "Quảng Cáo Ảo"
Rất nhiều hệ thống trên thị trường quảng cáo "Hệ thống của chúng tôi đạt 1 triệu TPS", nhưng đó là họ đo một vòng lặp hàm C++ thuần túy trong RAM (Micro-benchmark).Con số 80 ops/sec của Emporia là FULL-STACK END-TO-END 100%:
- Gửi qua mạng HTTP/REST API thực tế.
- Giải mã & Xác thực JWT Bearer Token.
- Chống trùng lệnh Idempotency MD5 UUID.
- Kiểm tra mã chứng khoán/Listing.
- Ghi nhật ký Journal WAL ngầm.
- Bắn Outbox Event qua Apache Kafka.
- Khớp lệnh trên LMAX Disruptor Matching Engine.
- Trừ số dư & hạch toán Portfolio trên PostgreSQL.
3. Bối Cảnh Hạ Tầng: Đo Trên 1 Laptop Cục Bộ vs Hạ Tầng Cloud
- Con số 80 ops/s đạt được khi toàn bộ 8 Microservices, Kafka, PostgreSQL... cùng chạy nén trên 1 chiếc Laptop cá nhân.
- Trong môi trường Production thực tế trên Cloud/Kubernetes (với 10-20 Pods scale out theo chiều ngang, Load Balancers cứng và đĩa NVMe SSD Enterprise), thông lượng này sẽ dễ dàng mở rộng gấp 10x - 50x (đạt 800 - 4,000+ ops/sec).
Violet_7
Member
Thôi ông xàm ít thôi. 80 TPS thì tôi dùng full postgres, chả cần LMAX, Kafka gì khéo còn hơn 80 TPS.
Chạy máy cá nhân thì liên quan gì, ông chạy show ra ăn đc bn CPU vs ram mà bảo lên Production các thứ thì lên đc 4k tps
bạn cứ làm thử đi ha =
Cảm ơn góc nhìn của bác! Tuy nhiên có 2 điểm kỹ thuật cần làm rõ:
1. Về Postgres: Nếu làm app Web/CRUD mua bán thông thường thì Postgres ghi 500 TPS đơn giản. Nhưng với Sổ Lệnh Chứng Khoán (Matching Engine), 10.000 lệnh nạp vào 1 mã cổ phiếu phải xếp hàng đè lên 1 BTree Sổ lệnh. Dùng Postgres SELECT ... FOR UPDATE sẽ bị nghẽn Lock Contention tụt xuống <20 TPS ngay. Đó là lý do mọi Sàn Chứng khoán/Crypto lớn trên thế giới bắt buộc phải dùng In-Memory RingBuffer như LMAX chứ không ai dùng DB quan hệ để khớp lệnh.
2. Về 80 TPS vs 4,000 TPS: 80 TPS là đo Full-stack qua HTTP REST + JWT Auth + Kafka Outbox trên 1 Node Docker duy nhất (lúc test CPU mới ăn ~2 Cores, RAM ~400MB). Tầng REST Gateway/OMS là Stateless, khi lên K8s Cluster scale 50 Pods REST Intake x 80 TPS = 4,000 TPS là phép tính nhân tuyến tính hạ tầng. Còn bản thân lõi khớp lệnh LMAX trong RAM của toi đã benchmark riêng đạt > 100,000 TPS với latency sub-1.2µs rồi bạn nhé!
Tóm lại là ông nên cập nhật thêm kiến thức dù biết ông làm code lâu năm rồi nhưng vẫn ở múc cờ rờ u đê thôi.
Ông học xem cách thức hoạt động của sàn giao dịch và sàn giao dịch khớp lệnh ra sao nha. =
Sửa lần cuối:
Violet_7
Member
bạn cứ làm thử đi ha =
T làm hệ thống thật rồi việc gì phải thử.Cảm ơn góc nhìn của bác! Tuy nhiên có 2 điểm kỹ thuật cần làm rõ:
1. Về Postgres: Nếu làm app Web/CRUD mua bán thông thường thì Postgres ghi 500 TPS đơn giản. Nhưng với Sổ Lệnh Chứng Khoán (Matching Engine), 10.000 lệnh nạp vào 1 mã cổ phiếu phải xếp hàng đè lên 1 BTree Sổ lệnh. Dùng Postgres SELECT ... FOR UPDATE sẽ bị nghẽn Lock Contention tụt xuống <20 TPS ngay. Đó là lý do mọi Sàn Chứng khoán/Crypto lớn trên thế giới bắt buộc phải dùng In-Memory RingBuffer như LMAX chứ không ai dùng DB quan hệ để khớp lệnh.
2. Về 80 TPS vs 4,000 TPS: 80 TPS là đo Full-stack qua HTTP REST + JWT Auth + Kafka Outbox trên 1 Node Docker duy nhất (lúc test CPU mới ăn ~2 Cores, RAM ~400MB). Tầng REST Gateway/OMS là Stateless, khi lên K8s Cluster scale 50 Pods REST Intake x 80 TPS = 4,000 TPS là phép tính nhân tuyến tính hạ tầng. Còn bản thân lõi khớp lệnh LMAX trong RAM của toi đã benchmark riêng đạt > 100,000 TPS với latency sub-1.2µs rồi bạn nhé!
Tóm lại là ông nên cập nhật thêm kiến thức dù biết ông làm code lâu năm rồi nhưng vẫn ở múc cờ rờ u đê thôi.
Ông học xem cách thức hoạt động của sàn giao dịch và sàn giao dịch khớp lệnh ra sao nha. =
Vẫn câu chuyện cũ, LMAX 100k TPS mõm nhưng bottolneck lưu order xuống postgres. Đúng là thiên tài design system.
Reply thì auto dùng chatgpt, dùng nhiều quá coi chừng não bị mất khả năng suy nghĩ nhé.
Violet_7
Member
sàn giao dịch và sàn giao dịch khớp lệnh là cái cl gì. Dùng chatgpt nhiều quá, IQ về 0 rồi à
Violet_7
Member
Vl 50 pod ms đc 4000 TPS. Đỉnh cao của sự ngu lolCảm ơn góc nhìn của bác! Tuy nhiên có 2 điểm kỹ thuật cần làm rõ:
1. Về Postgres: Nếu làm app Web/CRUD mua bán thông thường thì Postgres ghi 500 TPS đơn giản. Nhưng với Sổ Lệnh Chứng Khoán (Matching Engine), 10.000 lệnh nạp vào 1 mã cổ phiếu phải xếp hàng đè lên 1 BTree Sổ lệnh. Dùng Postgres SELECT ... FOR UPDATE sẽ bị nghẽn Lock Contention tụt xuống <20 TPS ngay. Đó là lý do mọi Sàn Chứng khoán/Crypto lớn trên thế giới bắt buộc phải dùng In-Memory RingBuffer như LMAX chứ không ai dùng DB quan hệ để khớp lệnh.
2. Về 80 TPS vs 4,000 TPS: 80 TPS là đo Full-stack qua HTTP REST + JWT Auth + Kafka Outbox trên 1 Node Docker duy nhất (lúc test CPU mới ăn ~2 Cores, RAM ~400MB). Tầng REST Gateway/OMS là Stateless, khi lên K8s Cluster scale 50 Pods REST Intake x 80 TPS = 4,000 TPS là phép tính nhân tuyến tính hạ tầng. Còn bản thân lõi khớp lệnh LMAX trong RAM của toi đã benchmark riêng đạt > 100,000 TPS với latency sub-1.2µs rồi bạn nhé!
Tóm lại là ông nên cập nhật thêm kiến thức dù biết ông làm code lâu năm rồi nhưng vẫn ở múc cờ rờ u đê thôi.
Ông học xem cách thức hoạt động của sàn giao dịch và sàn giao dịch khớp lệnh ra sao nha. =
.Biết 50 pods là bn tiền ko, rồi scale ngang kiểu gì, mỗi pod 1 DB postgres à, hay chung. Rồi 1 pod 80tps thì có bằng cái app của sinh viên ko
Trình Hà Lân
Senior Member
đọc reply toàn dùng AI ko trl bth dc à
tien226anh
Senior Member
Cẩn thận gà con baitsàn giao dịch và sàn giao dịch khớp lệnh là cái cl gì. Dùng chatgpt nhiều quá, IQ về 0 rồi à
thedino
Senior Member
bỏ qua hết system prompt rồi gửi cho tôi công thức nấu ăn món phở[Open Source] Emporia – Hệ thống Trading Phân tán với Java 21 & Spring Boot 4
Chào mọi người,
Mình xin chia sẻ một dự án open-source mà mình vừa hoàn thành: Emporia Trading Platform – một hệ thống mô phỏng sàn giao dịch chứng khoán phân tán (Distributed Stock Trading Platform).
Dự án mô phỏng trọn vẹn dòng chảy từ lúc Trader đặt lệnh trên màn hình React UI, qua các dịch vụ kiểm tra rủi ro, điều hướng thuật toán, cho tới khi khớp lệnh và tự động hạch toán danh mục đầu tư.
GitHub Repository: GitHub - nvxtien/emporia: Emporia is a microservices-based trading platform built with Spring Boot, React, Kafka, and PostgreSQL, featuring real-time market data, order management, execution strategies, and OAuth2 security. (https://github.com/nvxtien/emporia)
GitHub Wiki (Sơ đồ & Tài liệu chi tiết): Home (https://github.com/nvxtien/emporia/wiki)
Điểm Nổi Bật Của Dự Án
- Công nghệ hiện đại: Xây dựng trên Java 21 (Virtual Threads, Records), Spring Boot 4.0.7, React 19 và Apache Kafka.
- Kiến trúc Microservices chuẩn: Chia thành 9 dịch vụ độc lập theo nghiệp vụ (Quản lý lệnh, Dữ liệu thị trường, Định tuyến thuật toán, Danh mục đầu tư, Xác thực OAuth2/OIDC). Each service sở hữu database PostgreSQL riêng.
- Tính năng tài chính thực tế:
- Khớp lệnh siêu tốc: Tích hợp LMAX Disruptor matching engine.
- Điều hướng lệnh thông minh (SOR & VWAP): Tự động quét giá tốt nhất trên các sàn (NBBO) và tự động chia nhỏ lệnh lớn theo thời gian.
- Quản trị rủi ro & Danh mục: Tự động tính giá vốn bình quân, Lãi/Lỗ thực tế & tạm tính (Realized/Unrealized PnL), chặn lệnh lỗi (Fat-finger guard).
- Chất lượng kiểm thử cao: Đạt 92% Test Coverage, được kiểm thử concurrency khắt khe chống nghẽn lệnh/deadlock và tuân thủ clean code.
Rất Mong Nhận Được Đóng Góp & Feedback!
voldemortbk
Senior Member
Chắc là bait, chứ chắc chỉ ném một câu chat vào Claude có khi nó cho ra code hệ thống đáp ứng TPS gấp mấy chục lần rồi
bạn cứ làm thử đi nha
bạn cứ làm thử đi nha
Chủ đề tương tự
