Các trường hợp sử dụng luồng Kafka để thêm cửa hàng toàn cầu

Khi xác định cấu trúc liên kết trong các luồng kafka, một cửa hàng nhà nước toàn cầu có thể được thêm vào. Nó sẽ cần một chủ đề nguồn cũng như a ProcessorSupplier. Bộ xử lý nhận các bản ghi và về mặt lý thuyết có thể chuyển đổi chúng trước khi thêm chúng vào cửa hàng. Nhưng trong trường hợp khôi phục, các bản ghi được chèn trực tiếp từ chủ đề nguồn (changelog) vào kho lưu trữ trạng thái toàn cầu, bỏ qua chuyển đổi cuối cùng được thực hiện trong bộ xử lý.

   +-------------+             +-------------+              +---------------+
   |             |             |             |              |    global     |
   |source topic  ------------->  processor  +-------------->    state      |
   |(changelog)  |             |             |              |    store      |
   +-------------+             +-------------+              +---------------+
          |                                                         ^
          |                                                         |
          +---------------------------------------------------------+
              record directly inserted during restoration

StreamsBuilder # addGlobalStore (StoreBuilder storeBuilder, String topic, Consumed đã tiêu thụ, ProcessorSupplier stateUpdateSupplier) Thêm StateStore toàn cầu vào cấu trúc liên kết.

Theo tài liệu

LƯU Ý: bạn không nên sử dụng Bộ xử lý để chèn các bản ghi đã chuyển đổi vào cửa hàng trạng thái toàn cầu . Cửa hàng này sử dụng chủ đề nguồn dưới dạng thay đổi và trong quá trình khôi phục sẽ chèn các bản ghi trực tiếp từ nguồn . Bộ xử lý này nên được sử dụng để giữ cho StateStore được cập nhật.

Song song với lỗi lớn hiện đang mở trên trình theo dõi lỗi kafka: Bộ xử lý tùy chỉnh KAFKA-7663 được cung cấp trên addGlobalStore không được sử dụng khi khôi phục trạng thái từ chủ đề giải thích chính xác những gì được nêu trong tài liệu, nhưng dường như là một lỗi được chấp nhận.

Tôi tự hỏi liệu KAFKA-7663 có thực sự là một lỗi hay không. Theo tài liệu, nó dường như đã được thiết kế như thế này, trong trường hợp đó tôi phải vật lộn để hiểu trường hợp sử dụng.
Ai đó có thể giải thích các trường hợp sử dụng chính của API cấp thấp này không? Điều duy nhất tôi có thể nghĩ là xử lý các tác dụng phụ, ví dụ như thực hiện một số thao tác ghi nhật ký trong bộ xử lý.

Câu hỏi thưởng: Nếu chủ đề nguồn đóng vai trò là thay đổi của cửa hàng toàn cầu, khi một bản ghi bị xóa khỏi chủ đề vì việc lưu giữ đã hết hạn, liệu nó có bị xóa khỏi cửa hàng nhà nước toàn cầu không? Hoặc việc loại bỏ sẽ chỉ diễn ra trong cửa hàng sau khi phục hồi toàn bộ cửa hàng từ changelog.

Vâng, đây là một cái bẫy nhỏ khá kỳ lạ, nhưng tài liệu này là chính xác. Bộ xử lý cho một cửa hàng nhà nước toàn cầu không được làm bất cứ điều gì đối với các hồ sơ mà phải duy trì chúng vào cửa hàng.

AFAIK, đây không phải là một vấn đề triết học, chỉ là một vấn đề thực tế. Lý do đơn giản là hành vi bạn quan sát ... Luồng coi chủ đề đầu vào là chủ đề thay đổi cho cửa hàng và do đó bỏ qua bộ xử lý (cũng như khử lưu huỳnh) trong quá trình khôi phục.

Lý do phục hồi trạng thái bỏ qua bất kỳ quá trình xử lý nào là thông thường dữ liệu trong một thay đổi giống hệt với dữ liệu trong cửa hàng, do đó thực sự sẽ sai khi làm bất cứ điều gì mới đối với nó. Thêm vào đó, sẽ hiệu quả hơn khi lấy các byte ra khỏi dây và ghi số lượng lớn chúng vào các cửa hàng nhà nước. Tôi nói "thường" bởi vì trong trường hợp này, chủ đề đầu vào không giống như một chủ đề thay đổi thông thường, ở chỗ nó không nhận được ghi trong khi đặt cửa hàng.

Đối với những gì nó có giá trị, tôi cũng đấu tranh để hiểu trường hợp sử dụng. Dường như, chúng ta nên:

1. Loại bỏ hoàn toàn bộ xử lý đó và luôn luôn đổ dữ liệu nhị phân ra khỏi dây vào các cửa hàng, giống như phục hồi.
2. Thiết kế lại các cửa hàng toàn cầu để cho phép biến đổi tùy ý trước cửa hàng toàn cầu. Chúng ta có thể:
   • tiếp tục sử dụng chủ đề đầu vào và giải tuần tự hóa và gọi bộ xử lý trong quá trình khôi phục, HOẶC
   • thêm một thực changelog cho các cửa hàng trên toàn cầu, chẳng hạn mà chúng ta muốn thăm dò ý kiến các chủ đề đầu vào, áp dụng một số biến đổi, sau đó ghi vào các cửa hàng toàn cầu và toàn cầu-store-changelog. Sau đó, chúng ta có thể sử dụng thay đổi (không phải đầu vào) để phục hồi và nhân rộng.

Nhân tiện, nếu bạn muốn hành vi thứ hai, bạn có thể ước chừng nó ngay bây giờ bằng cách áp dụng các biến đổi của bạn và sau đó sử dụng to(my-global-changelog)để tạo ra một chủ đề "thay đổi". Sau đó, bạn sẽ tạo cửa hàng toàn cầu để đọc từ my-global-changelogthay vì đầu vào.

Vì vậy, để cung cấp cho bạn câu trả lời trực tiếp, KAFKA-7663 không phải là một lỗi. Tôi sẽ bình luận về vé đề xuất biến nó thành một yêu cầu tính năng.

Phần thưởng trả lời: Các chủ đề đóng vai trò thay đổi cho các cửa hàng nhà nước không được cấu hình với lưu giữ. Thực tế, điều này có nghĩa là bạn nên ngăn chặn sự tăng trưởng vô hạn bằng cách cho phép nén và vô hiệu hóa lưu giữ nhật ký.

Trong thực tế, dữ liệu cũ không còn lưu giữ và bị rơi không phải là một "sự kiện" và người tiêu dùng không có cách nào để biết nếu / khi nó xảy ra. Do đó, không thể xóa dữ liệu khỏi các cửa hàng nhà nước để đáp ứng với sự kiện này. Nó sẽ xảy ra như bạn mô tả ... các hồ sơ sẽ chỉ ngồi đó trong cửa hàng toàn cầu vô thời hạn. Nếu / khi một cá thể được thay thế, cái mới sẽ khôi phục từ đầu vào và (rõ ràng) chỉ nhận các bản ghi tồn tại trong chủ đề tại thời điểm đó. Do đó, toàn bộ cụm Streams sẽ cuộn lên với một cái nhìn không nhất quán về nhà nước toàn cầu. Đó là lý do tại sao bạn nên vô hiệu hóa giữ chân.

Cách đúng để "thả" dữ liệu cũ khỏi cửa hàng sẽ là viết một bia mộ cho khóa mong muốn vào chủ đề đầu vào. Điều này sau đó sẽ được truyền chính xác đến tất cả các thành viên của cụm, được áp dụng chính xác trong quá trình phục hồi và được nén bởi các nhà môi giới.

Tôi hy vọng tất cả điều này sẽ giúp. Chắc chắn, vui lòng bấm vào vé và giúp chúng tôi định hình API để trực quan hơn!