2010-10-06 19 views
5

Đây là mô tả sự cố Chúng tôi có hàng nghìn thiết bị (khoảng 4k -5k) thông qua đó chúng tôi phải đọc dữ liệu liên tục, cứ sau 2 phút hoặc 30 giây. Mỗi thiết bị có IP duy nhất của nó. Dữ liệu này sẽ được thu thập và sau đó được lưu trữ trong cơ sở dữ liệu. Những thiết bị này ở vị trí 100 của cả nước. Dữ liệu sẽ không được đọc 24X7 nhưng trong ít nhất 12 giờ.Làm thế nào để giao tiếp với 1000 của socket simultaneosuly trong Java?

Có một ứng dụng web sẽ yêu cầu tại một số thời điểm để hiển thị dữ liệu đang được thu thập dữ liệu thông qua các thiết bị này. Chúng tôi sẽ biết dữ liệu mà từ đó thiết bị được yêu cầu.

Đây là cách chúng ta nghĩ rằng chúng ta có thể thực hiện trong Java

Dung dịch A: Trong mỗi vị trí, chỉ định một máy mà sẽ đóng vai trò như máy chủ và sẽ đọc dữ liệu từ số x của thiết bị. Dữ liệu này sẽ được chuyển đến máy chủ trung tâm cứ sau 1 giờ. Trên máy được chỉ định này, dữ liệu được kéo và lưu trữ cục bộ (tệp phẳng hoặc trong cơ sở dữ liệu bộ nhớ)

Trong trường hợp này, chúng tôi sẽ có nhiều máy chủ như số lượng vị trí. cho ví dụ như chúng ta có thể kết thúc có 1500 máy chủ/máy quản lý mà trở thành một cơn ác mộng.

Giải pháp B:

Chúng tôi có 8-10 máy chủ trung tâm và mỗi máy chủ đọc dữ liệu từ một loạt các máy móc. Các dữ liệu được xếp hàng đợi và được chọn theo thứ tự mà nó đã đến.

Máy chủ đẩy dữ liệu vào cơ sở dữ liệu.

Khách hàng nhận dữ liệu như thế nào?

Trong giải pháp B, máy khách lấy nó làm cơ sở dữ liệu, giả sử dữ liệu đã được đẩy vào db và vẫn không xếp hàng đợi.

Bạn nghĩ điều gì sẽ hoạt động tốt hơn?

Bất kỳ thiết kế/giải pháp thay thế nào?

Chúng ta có nên nghĩ về lập trình tại máy chủ với Unix/Perl hay không. Chúng tôi không muốn sử dụng C++ vì một số lý do khác.

+1

Bao nhiêu dữ liệu được thu thập sau mỗi 2.5 phút hoặc 30 giây? Ngoài ra, hãy nhìn vào Java NIO - số lượng kết nối này không khó cho Java trong những ngày này. –

+0

FYI - Liên tục! = Một lần 2,5 phút hoặc 30 giây ...;) – NotMe

+0

Hệ thống dựa trên khách hàng java hay chỉ là các phần cứng ngẫu nhiên "câm" – dstarh

Trả lời

4

Yêu cầu được nêu trong câu hỏi của bạn không ngụ ý 1000s của kết nối đồng thời, vì bạn có thể dễ dàng tạo kết nối lại sau mỗi 30 giây. Giả sử kết nối có thể được xử lý trong vòng 500 ms, để lại 5000/30 * 0.5 ~ = 100 kết nối đồng thời. Bất kỳ hệ điều hành phong nha nào cũng có thể xử lý được nhiều điều đó. Với sự đồng thời thấp như vậy, bạn thậm chí có thể lấy đi bằng cách sử dụng một máy chủ duy nhất với mỗi kết nối được làm việc bởi một luồng chuyên dụng.

Do đó, thiết kế của bạn nên tập trung vào các yêu cầu khác của bạn. Một vài ý tưởng:

  • Thiết bị có được tường lửa không? Với giải pháp A, bạn sẽ có các kết nối gửi đi từ mỗi vị trí, với giải pháp B, bạn sẽ có các kết nối đến.
  • Bạn cần loại độ tin cậy nào? Ví dụ, bạn có cần phải ghi lại các phép đo nếu kết nối internet của một địa điểm không hoạt động? Điều đó sẽ ngụ ý một máy chủ cục bộ đệm các phép đo.
+0

5000/30 * 0.5 ~ = 100 kết nối đồng thời. Vâng, đó là số đúng. Tất cả các thiết bị này đều nằm trong một VPN. Cảm ơn bạn đã đặt câu hỏi này. – vsingh

2

Hãy thử Netty.

+0

Điều này có vẻ khá nặng nề đối với những gì chúng tôi đang cố gắng làm. – vsingh

1

Bạn chưa đề cập đến việc khách hàng nói chuyện với máy chủ, chứ không phải ngược lại. Đó có phải là một lựa chọn không? Bạn cũng không đề cập đến khối lượng dữ liệu đang được chuyển.

Các số liệu bạn đề cập không có vẻ bất hợp lý đối với máy chủ Java (với kết nối nhóm thích hợp, v.v.). Hãy thử tạo mẫu một số giải pháp chỉ để kiểm tra các thông tin liên lạc và luồng/kết nối. Và xem các khuôn khổ như Apache Mina.

+0

Khách hàng sẽ nói chuyện với máy chủ và máy chủ sẽ lấy dữ liệu từ db đã được thu thập bởi ổ cắm. Sẽ nhìn vào Apache Mina. – vsingh

2

Nếu có thể tôi nghĩ khách hàng của bạn nên gửi tin nhắn JMS hoặc một số loại hàng đợi thì bạn xử lý hàng đợi để lưu trữ trong cơ sở dữ liệu. Có ActiveMQ mà sẽ làm việc độc đáo cho việc này. Cũng có SQS (Từ amazon) nếu bạn thích triển khai dựa trên đám mây thì các máy chủ java của bạn nói chuyện với DB chủ có thể chỉ cần kéo từ đó.

3

Nếu bạn duy trì kết nối, bạn sẽ có thể thăm dò ý kiến ​​mỗi kết nối dưới 20 micro giây mỗi kết nối. Điều này có nghĩa là bạn có thể thăm dò ý kiến ​​mọi kết nối trong vòng dưới 100 ms chỉ là một chuỗi không chặn. (có lẽ cách hiệu quả nhất để thực hiện việc này)

Sử dụng Bộ chọn là cách tiếp cận tốt hơn vì nó cung cấp Bộ các kết nối sẵn sàng.

Nếu bạn tạo kết nối mới mỗi lần, điều này tốn kém hơn nhiều nhưng có thể mất 20 mili giây, (dài hơn tùy thuộc vào độ trễ của mạng của bạn). Để kết nối 5000 kết nối trong 30 giây, bạn cần giữ 3-4 hoạt động bất cứ lúc nào. (hầu hết thời gian sẽ được dành để thiết lập và hủy kết nối) Bạn có thể làm tất cả điều này với một luồng, nhưng việc sử dụng một hồ bơi nhỏ có thể đơn giản hơn.

+0

Nói về giới hạn thời gian, chúng ta cần phải tạo một chuỗi, mở một kết nối, đọc dữ liệu, đóng kết nối và chuỗi hoàn tất. Nó sẽ không có ý nghĩa để giữ cho thread sống trong 30 giây. – vsingh

+0

Bạn không cần 1000 chủ đề, nhưng nếu bạn có một nhóm luồng với 1000 nhiệm vụ (xem Executor) thì bạn sẽ giữ cho Thread luôn hoạt động vì bạn sẽ bỏ phiếu cho một thiết bị hoặc một thiết bị khác. Đôi khi chi phí tạo và hủy các chủ đề lớn hơn chi phí giữ chúng. Tương tự như vậy, nếu bạn có thể giữ các kết nối mở, bạn sẽ giảm chi phí của máy chủ và có thể là khách hàng đáng kể. –

Các vấn đề liên quan