Bạn có thể sử dụng memcached, nhưng một lần nữa mọi người sẽ truy cập vào máy chủ cơ sở dữ liệu của bạn. Trong trường hợp của bạn, bạn đang nói rằng kết quả truy vấn là loại dai dẳng vì vậy, việc lưu vào bộ nhớ cache các phản hồi JSON từ Dịch vụ Web của bạn có thể có ý nghĩa hơn.
Điều này có thể được thực hiện bằng cách sử dụng Reverse Proxy với bộ nhớ cache được tích hợp sẵn. Tôi đoán một ví dụ có thể giúp bạn nhiều nhất về cách chúng tôi thực hiện với Jetty (Java) và NGINX:
Trong thiết lập của chúng tôi, chúng tôi có một phiên bản Jetty (Java) phục vụ một API cho các ứng dụng khách di động của chúng tôi. API đang lắng nghe trên localhost:8080 / api và trả về kết quả JSON được tìm nạp từ một số truy vấn trên cơ sở dữ liệu Mysql cục bộ.
Tại thời điểm này, chúng tôi có thể cung cấp API trực tiếp cho khách hàng của mình, nhưng ở đây có Reverse Proxy:
Phía trước API đặt một máy chủ web NGINX lắng nghe từ 0.0.0.0:80/ (ở mọi nơi, cổng 80) Khi một ứng dụng khách di động kết nối với 0.0.0.0:80/api, Reverse Proxy tích hợp sẵn sẽ cố gắng tìm nạp chuỗi truy vấn chính xác từ đó là bộ nhớ cache. Nếu không thành công, nó sẽ tìm nạp nó từ localhost:8080 / api, đặt nó vào bộ nhớ cache và cung cấp giá trị mới được tìm thấy trong bộ nhớ cache.
Lợi ích:
- Bạn có thể sử dụng các tính năng bổ sung khác của NGINX:nén GZIP tự động của các tệp JSON đã lưu trong bộ nhớ cache
- Chấm dứt điểm cuối SSL tại NGINX.
- Nhân viên NGINX có thể mang lại lợi ích cho bạn, khi bạn có nhiều kết nối hơn, tất cả đều yêu cầu dữ liệu từ bộ nhớ đệm.
- Bạn có thể hợp nhất các điểm cuối dịch vụ của mình
Hãy nghĩ về việc vô hiệu hóa bộ nhớ cache:
Bạn phải nghĩ đến việc vô hiệu hóa bộ nhớ cache. Bạn có thể yêu cầu NGINX giữ bộ nhớ cache của nó trong một tuần cho tất cả yêu cầu HTTP 200 cho localhost:8080 / api hoặc 1 phút cho tất cả các mã trạng thái HTTP khác. Nhưng nếu đến thời điểm mà bạn muốn cập nhật API trong vòng chưa đầy một tuần, thì bộ nhớ cache không hợp lệ, vì vậy bạn phải xóa nó bằng cách nào đó hoặc giảm thời gian lưu vào bộ nhớ đệm xuống một giờ hoặc một ngày (để hầu hết mọi người sẽ nhấn bộ nhớ cache).
Đây là những gì chúng tôi làm:Chúng tôi đã chọn xóa bộ nhớ cache, khi nó bị bẩn. Chúng tôi có một JOB khác đang chạy trên Máy chủ lắng nghe một sự kiện Update-API được kích hoạt qua Con rối. JOB sẽ lo việc xóa bộ nhớ cache NGINX cho chúng tôi.
Một ý tưởng khác là thêm chức năng xóa bộ nhớ cache bên trong Dịch vụ Web của bạn. Lý do chúng tôi quyết định chống lại giải pháp này là:Dịch vụ Web sẽ phải biết nó chạy sau proxy ngược, điều này phá vỡ sự phân tách các mối quan tâm. Nhưng tôi phải nói rằng, nó phụ thuộc vào những gì bạn đang lên kế hoạch.
Một điều khác, điều này sẽ làm cho Dịch vụ web của bạn trở nên đúng đắn hơn sẽ phân phát các tiêu đề ETAG đúng và hết hạn trong bộ nhớ cache với mỗi tệp JSON. Một lần nữa, chúng tôi đã không làm điều đó, vì chúng tôi có một Sự kiện cập nhật lớn, thay vì những sự kiện nhỏ cho mỗi tệp.
Ghi chú bên lề:
- Bạn không cần phải sử dụng NGINX, nhưng nó thực sự dễ dàng để định cấu hình
- NGINX và Apache có hỗ trợ SSL
- Ngoài ra còn có Reverse Proxy (https://www.varnish-cache.org) nổi tiếng, nhưng theo hiểu biết của tôi thì nó không hỗ trợ SSL (chưa?)
Vì vậy, nếu bạn sử dụng Varnish trước Dịch vụ web + SSL, bạn sẽ sử dụng cấu hình như:NGINX -> Varnish -> Dịch vụ web.
Tài liệu tham khảo:- Máy chủ NGINX:http://nginx.com- Varnish Reverse Proxy:https://www.varnish-cache.org- Puppet IT Automation:https://puppetlabs.com- Hướng dẫn ngược proxy NGINX:http:/ /www.cyberciti.biz/faq/howto-linux-unix-setup-nginx-ssl-proxy/ http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.html
