Tại sao sử dụng Singleton để quản lý kết nối db?

Question

Tôi biết điều này đã được yêu cầu trước đây và ở khắp mọi nơi nhưng tôi không thể có được một lời giải thích rõ ràng vì vậy tôi sẽ pitch nó một lần nữa. Vì vậy, những gì là tất cả các fuss về việc sử dụng một singleton để kiểm soát kết nối db trong ứng dụng web của bạn? Một số thích nó một số ghét nó tôi không hiểu nó. Từ những gì tôi đã đọc, "đó là để đảm bảo rằng luôn luôn chỉ có một kết nối hoạt động với DB của bạn". Ý tôi là tại sao lại là một điều tốt? 1 hoạt động kết nối DB trên một ứng dụng web dữ liệu điều khiển xử lý nhiều yêu cầu mỗi giây phép thuật rắc rối phải không? Vì bất cứ lý do gì, không ai có thể giải thích đúng về điều này. Tôi đã được trên tất cả các trang web. Tôi biết tôi dày.

Answer 1

Bạn nói đúng - thường thì đây không phải là điều bạn muốn.

Tuy nhiên, có rất nhiều trường hợp bạn cần phải điều tiết chính mình xuống một kết nối duy nhất. Bằng cách tuần tự hóa quyền truy cập của bạn vào cơ sở dữ liệu thông qua singleton, bạn có thể giải quyết các vấn đề khác hoặc các ràng buộc như tải, băng thông, v.v.

Tôi đã thực hiện điều tương tự trong quá khứ cho một ứng dụng xử lý hàng loạt. Thay vào đó, mặc dù, tôi đã sử dụng một semaphore để đồng bộ hóa quyền truy cập vào cơ sở dữ liệu vì vậy tôi có thể cho phép n hoạt động db đồng thời.

Answer 2

Đảm bảo rằng mỗi khách hàng sử dụng trang web của bạn chỉ nhận được một kết nối với db. Bạn thực sự không muốn kết nối mới được thực hiện mỗi khi người dùng thực hiện hành động sẽ tạo truy vấn db. Không chỉ vì lý do hiệu suất với việc bắt tay kết nối, mà còn giảm tải trên máy chủ db.

Kết nối DB là một mặt hàng quý giá và kỹ thuật này giúp giảm thiểu số lượng được sử dụng tại bất kỳ thời điểm nào.

Answer 3

Người ta có thể muốn sử dụng một singleton do ràng buộc máy chủ cơ sở dữ liệu, ví dụ, một máy chủ có thể giới hạn số lượng kết nối.

Lý do chính của tôi là bạn biết những kết nối nào có thể được quản lý/đóng, v.v., chỉ giúp mọi thứ được tổ chức hơn một chút khi bạn không có kết nối dự phòng không cần thiết.

Answer 4

Tôi không nghĩ đó là câu trả lời đơn giản. Ví dụ trên ASP.NET, nền tảng thực hiện kết nối tổng hợp theo mặc định, vì vậy nó sẽ tự động điều chỉnh một "hồ bơi" của các kết nối và tái sử dụng chúng để bạn không liên tục tạo và phá hủy các đối tượng đắt tiền.

Tuy nhiên, giả sử bạn đang viết một ứng dụng thu thập dữ liệu theo dõi 200 nguồn đầu vào riêng biệt. Mỗi khi một trong những đầu vào đó thay đổi, bạn sẽ tắt một luồng ghi lại sự kiện đó vào cơ sở dữ liệu. Tôi có thể nói đó có thể là một thiết kế tồi tệ nếu có một cơ hội thậm chí một phần nhỏ trong số đó có thể bắn ra cùng một lúc. Đột nhiên có 20 hoặc 40 kết nối cơ sở dữ liệu hoạt động không hiệu quả. Nó có thể là tốt hơn để xếp hàng các bản cập nhật, và miễn là có bản cập nhật còn lại trong hàng đợi, một kết nối singleton chọn chúng ra khỏi hàng đợi và thực thi chúng trên máy chủ. Nó hiệu quả hơn bởi vì bạn chỉ phải thương lượng kết nối và xác thực một lần. Khi không có hoạt động nào trong một thời gian, bạn có thể chọn đóng kết nối. Loại hành vi này sẽ khó thực hiện mà không cần một người quản lý tài nguyên trung tâm như một singleton.

Answer 5

"chỉ một kết nối hoạt động" là một tuyên bố rất hẹp để minh hoạ. Nó cũng có thể là một singleton quản lý một nhóm kết nối. Điểm của một singleton cho các kết nối cơ sở dữ liệu là bạn không muốn mọi người tiêu dùng tạo kết nối của riêng nó hoặc thiết lập các kết nối.

Answer 6

Tôi nghĩ bạn có thể muốn cụ thể hơn về ", sử dụng singleton để kiểm soát kết nối db trong ứng dụng web của bạn". Lý tưởng nhất, một đối tượng java.sql.Connection sẽ không phải là là luồng an toàn, nhưng javax.sql của bạn.DataSource có thể muốn kết nối các nhóm, vì vậy bạn nên đi đến một cá thể duy nhất của nó để chia sẻ việc gộp nhóm.

Answer 7

Ứng dụng web hiệu suất cao (hoặc thậm chí trung bình) sử dụng cơ sở dữ liệu connection pooling, do đó, một kết nối DB có thể được chia sẻ giữa nhiều yêu cầu web. Singleton thường là đối tượng quản lý hồ bơi này. Tôi nghĩ rằng động cơ để sử dụng một singleton là để chống giả mạo chống lại lập trình bảo trì mà có thể nếu không nhanh chóng nhiều người trong số các đối tượng này không cần thiết.

Answer 8

bạn đang tìm kiếm thêm một kết nối cho mỗi yêu cầu, không phải một kết nối cho toàn bộ ứng dụng. bạn vẫn có thể kiểm soát quyền truy cập vào nó thông qua một singleton (lưu trữ kết nối trong bộ sưu tập HttpContext.Items).

Answer 9

"đó là đảm bảo luôn có một kết nối hoạt động với DB của bạn". Tôi nghĩ rằng sẽ được tuyên bố tốt hơn để đảm bảo mỗi CLIENT chỉ có một kết nối hoạt động với DB của bạn. Lý do tại sao điều này là cực kỳ quan trọng là bởi vì bạn muốn ngăn chặn deadlocks. Nếu tôi có HAI kết nối cơ sở dữ liệu mở (như là một khách hàng) tôi có thể được cập nhật trên một kết nối, sau đó tôi có thể cố gắng cập nhật cùng một hàng trong một kết nối khác. Điều này sẽ là một bế tắc mà cơ sở dữ liệu không thể phát hiện. Vì vậy, ý tưởng về singleton về cơ bản là đảm bảo rằng có một đối tượng là người chịu trách nhiệm bàn giao các kết nối cơ sở dữ liệu cho từng khách hàng. Về cơ bản. Bạn không cần phải có một singleton cho điều này, nhưng hầu hết mọi người sẽ cho bạn biết nó chỉ có ý nghĩa rằng hệ thống chỉ có một.

Answer 10

Giả sử Java ở đây, nhưng có liên quan đến hầu hết các công nghệ khác.

Tôi không chắc chắn liệu bạn có nhầm lẫn việc sử dụng một bản đơn thuần với service locator hay không. Cả hai đều là mẫu thiết kế. Mẫu thiết bị định vị dịch vụ được sử dụng bởi các ứng dụng để đảm bảo rằng có một lớp duy nhất được giao phó với trách nhiệm thu thập và cung cấp quyền truy cập vào cơ sở dữ liệu, tệp, hàng đợi JMS, v.v.

Hầu hết các trình định vị dịch vụ được thực hiện như đơn, vì có không cần nhiều người định vị dịch vụ để thực hiện cùng một công việc. Bên cạnh đó, nó rất hữu ích để lưu trữ thông tin thu được từ lần tra cứu đầu tiên mà sau này có thể được sử dụng bởi các ứng dụng khách khác của trình định vị dịch vụ.

Bằng cách này, các cuộc tranh luận về

"đó là để đảm bảo rằng luôn luôn có chỉ có một kết nối hoạt động với DB của bạn"

là sai và gây hiểu nhầm. Có thể kết nối có thể được đóng/thu hồi nếu không hoạt động trong một thời gian dài. Vì vậy, bộ nhớ đệm một kết nối đến cơ sở dữ liệu được cau mày. Có một sai lệch từ lập luận này; "sử dụng lại" kết nối thu được từ nhóm kết nối được khuyến khích miễn là bạn làm như vậy với cùng ngữ cảnh, tức là trong cùng một yêu cầu HTTP hoặc yêu cầu của người dùng (tùy theo điều kiện nào được áp dụng). Điều này thực hiện rõ ràng, từ quan điểm của hiệu suất, kể từ khi thiết lập kết nối mới có thể chứng minh là một hoạt động đắt tiền.