Lưu trữ phiên đáng tin cậy nhất trong PHP: Memcache, cơ sở dữ liệu hoặc tệp là gì? [đóng cửa]


10

Cách tốt nhất và an toàn nhất để xử lý các phiên PHP là gì. Là cách tốt nhất để lưu trữ phiên trong:

  1. Cơ sở dữ liệu (đáng tin cậy hơn, nhưng tắc nghẽn cao, tốc độ chậm, không tốt cho các trang web sử dụng cơ sở dữ liệu cao)?

  2. Memcache (siêu nhanh, nhưng phân phối nhiều vấn đề bảo mật hơn, cơ hội mất dữ liệu khi máy chủ khởi động lại và cơ hội mất dữ liệu khi bộ nhớ cache đầy)?

  3. Các tệp (tùy chọn mặc định, tôi đoán chậm vì nó đọc và ghi từ tệp I / O, ít bảo mật hơn, v.v.).

Phương pháp nào là tốt nhất? Các vấn đề và những điều tốt của mỗi phương pháp là gì?


2
Tôi tin rằng bạn nên chỉ định nếu bạn chỉ sử dụng một máy hoặc nếu ứng dụng được phân phối, vì nó sẽ ảnh hưởng lớn đến các câu trả lời.
Arseni Mourzenko

1
@haylem đây là nơi thích hợp nhất để đặt câu hỏi này, câu hỏi không phải lập trình của nó là vấn đề về khái niệm lập trình,
user1179459

3
Đây thực sự là một câu hỏi kém vì 'tốt nhất' phụ thuộc vào hoàn cảnh cụ thể của bạn. 'Tốt nhất' cho Facebook có lẽ không giống với 'tốt nhất' cho trang chủ cá nhân của bạn.
GrandmasterB

1
@GrandmasterB Tôi biết rằng đó là lý do tại sao tôi hỏi rõ ràng "những vấn đề và những điều tốt của mỗi phương pháp đó là gì?" để tìm ra cái nào là tốt nhất cho tôi
dùng1179459

Câu trả lời:


6

Tốt nhất là lưu trữ tại Memcached vì chúng tôi có thể dễ dàng giải quyết các vấn đề khác (kích thước bộ đệm, bảo mật, v.v.)

facebook là người tiêu dùng số 1 của memcached. Vui lòng đọc nếu quan tâm: http://www.facebook.com/note.php?note_id=39391378919

Làm thế nào để giải quyết các vấn đề khác?


4

Đối với phần lớn các ứng dụng hàng ngày, việc giữ các phiên trong cơ sở dữ liệu là tốt. Khối lượng & mức độ đồng thời mà một máy chủ sql có thể xử lý sẽ là quá đủ. Điều quan trọng là giữ cho mỗi mục có kích thước nhỏ và thanh lọc các hàng không cần thiết một cách đều đặn. Và lập chỉ mục thích hợp, tất nhiên.

Hệ thống tập tin - Tôi chưa bao giờ thấy cần phải làm điều đó. Tôi thích sự đơn giản của việc quản lý các hàng trong bảng hơn là hàng ngàn tệp nhỏ. Ngoài ra, bạn không thể truy vấn trên các tệp nếu bạn muốn tìm hiểu số liệu thống kê phiên.

Hãy nhớ rằng, với PHP, thật dễ dàng để trao đổi các trình xử lý phiên. Vì vậy, bạn có thể bắt đầu với một định dạng lưu trữ và di chuyển sang định dạng khác mà không gặp quá nhiều khó khăn.


4

Còn việc sử dụng công cụ lưu trữ MEMOR trong MySQL thì sao?

Nó không nhanh như Memcache nhưng có lợi thế là bạn có thể sử dụng SQL đơn giản và bạn cũng có thể sử dụng công cụ lưu trữ thông thường khi không cần thiết và chuyển sang MEMOR khi số lượng người dùng / yêu cầu tăng lên.

Tôi đang sử dụng nó để lưu trữ một lượng lớn dữ liệu thống kê trong một ứng dụng web thường xuyên thay đổi để nó không được sử dụng để xử lý các phiên nhưng tôi nghĩ rằng nó rất phù hợp cho mục đích này.


3

Bài đăng trên blog này cho thấy kết quả so sánh hiệu suất của các công cụ lưu trữ phiên khác nhau với Magento và dường như họ đã kết luận rằng có tới khoảng 75 người dùng đồng thời không thực sự có sự khác biệt về hiệu suất giữa chúng.

Tôi nghĩ rằng ở các cấp độ này (chúng có khoảng 5 giao dịch một giây, tương đương khoảng 430 nghìn lượt truy cập trong khoảng thời gian 12 giờ), chi phí trong mọi thứ khác chi phối các số hiệu suất bạn thấy vì tệp / DB / Memcache / Redis sẽ vui vẻ xử lý giao thông mà không đổ mồ hôi nếu sử dụng đúng cách.

Điều đó để lại các yếu tố khác như khả năng mở rộng, độ tin cậy và bảo mật.

Trước tiên tôi muốn nói rằng bất cứ điều gì ảnh hưởng đến việc lưu trữ tệp của bạn cũng có thể sẽ thỏa hiệp bất cứ điều gì khác vì kẻ tấn công sau đó có thể sửa đổi mã ứng dụng của bạn hoặc ít nhất là khám phá các khóa và giao thức / thông tin truy cập lưu trữ ngay cả khi chúng chỉ đọc truy cập. Lưu trữ tệp sẽ hoạt động tốt cho một trang web khối lượng thấp, dễ thiết lập và dễ lý do. Nhiều như bạn nói bạn đã đánh vào đĩa, một lần đọc DB cũng sẽ đánh vào đĩa và nếu DB có thể lưu trữ nó, hệ điều hành của bạn cũng có thể đã lưu vào tệp phiên. Ngoài ra, một tệp của nó được đọc và hệ thống tệp của bạn rất tuyệt vời khi nhận được nó nếu bạn đã biết tên của nó. Nếu bạn đang sử dụng PHP, bạn có biết hệ thống phải đọc bao nhiêu tệp chỉ để phục vụ ứng dụng của bạn không? Nhược điểm là bạn có thể '

Memcache tương đối nhanh và nếu bạn đang xem xét các giải pháp lớp Memcache rộng hơn (Redis, v.v.), có một số thậm chí sẽ hứa hẹn sự kiên trì với tốc độ đọc bộ nhớ để bạn có được hầu hết cả hai thế giới. Chúng cũng tương đối đơn giản để lý do và bản chất giá trị khóa của các phiên là chính xác những gì chúng đã được thiết kế để làm. Bạn có biết bạn sẽ phải bỏ bao nhiêu tiền vào một phiên để điền vào một trong số này không? Dù bằng cách nào, tất cả các lựa chọn của bạn sẽ buộc bạn phải thỏa hiệp nếu bạn đạt được năng lực của họ. Đĩa chứa đầy các tệp (yếu tố số lượng và kích thước ở đây), các bộ lưu trữ bộ đệm chứa đầy dung lượng và cơ sở dữ liệu có số lượng hàng hạn chế và giới hạn dung lượng đĩa giống như cách tiếp cận tệp. Ngoài ra, các hệ thống này chỉ được phân phối nếu bạn chạy chúng theo kiểu phân tán. Hầu hết chỉ hoạt động tốt với một thiết lập máy chủ duy nhất. Nếu bạn phân phối chúng thì có lẽ bạn đã có máy chủ web / máy chủ cơ sở dữ liệu phân phối, v.v. nên các vấn đề hệ thống phân tán của bạn chắc chắn sẽ không xuất hiện từ lựa chọn lưu trữ phiên của bạn. Tuy nhiên, khi bạn muốn tăng gấp 10 lần lưu lượng / dung lượng, v.v., việc này sẽ trở nên tự nhiên hơn nhiều so với sơ đồ lưu trữ tệp. Một số cửa hàng khóa / giá trị cũng sẽ cho phép bạn tiến hành phân tích đơn giản dữ liệu phiên tương đối dễ dàng nhưng hầu hết sẽ không đưa bạn đến bất cứ nơi nào gần những gì SQL có thể làm.

Tôi không chắc tại sao bạn đề xuất cơ sở dữ liệu đó có thể đáng tin cậy hơn các tùy chọn khác, nhưng tôi nhận được sự hấp dẫn của cơ sở dữ liệu vì ứng dụng PHP của bạn có thể đã sử dụng nó. Điều này có nghĩa là bạn không thêm phụ thuộc máy chủ khác và có thể bạn có thể sử dụng lại cùng một kết nối bạn sử dụng để tìm nạp dữ liệu phiên để lấy dữ liệu người dùng để bạn không phải thiết lập một cho dữ liệu, một cho Memcache, v.v. Nếu bạn lập chỉ mục bảng tốt, nó cũng sẽ thực hiện nhanh chóng hợp lý và cung cấp ngữ nghĩa khá đơn giản mà bạn đã quen thuộc để gặt hái các phiên cũ hoặc thậm chí phân tích dữ liệu phiên (Tôi không chắc tại sao bạn lại muốn và nếu bạn không, thì điều này có lẽ không ' vấn đề rất nhiều). Mở rộng quy mô lớn không tầm thường như với Redis,

Tôi nghĩ rằng sự lựa chọn này không quá quan trọng ngay từ đầu. Mỗi cách tiếp cận đều có những thách thức và lợi thế và những điều bạn phải suy nghĩ. Nói chung, có lẽ bạn có thể thoát khỏi việc chỉ sử dụng các giá trị mặc định của PHP / bất kỳ khuôn khổ nào bạn sử dụng hoặc thậm chí chỉ là thứ dễ nhất để thực hiện. Nếu lựa chọn trở nên tồi tệ sau này, các phân tích hiệu suất của bạn sẽ cho bạn biết và bạn sẽ được trang bị dữ liệu bạn cần để đưa ra các lựa chọn phù hợp với tính chất cụ thể của lưu lượng truy cập bạn nhận được. Trước mắt, tất cả những gì bạn có thể có một cách hợp lý là đầu cơ chung.


0

Nó phụ thuộc vào nhu cầu của bạn.

Có một số khác biệt giữa các tập tin và lưu trữ cơ sở dữ liệu. Xem câu hỏi này .

Tuy nhiên, bạn có thể thực hiện những gì được thực hiện trong Rails 3 theo mặc định và chỉ sử dụng cookie được mã hóa cho phiên của bạn. Vì vậy, bạn mã hóa tất cả các giá trị theo cách mà chỉ bạn mới có thể giải mã nó sau này (ví dụ: khóa riêng / khóa chung) và bạn để máy khách thực hiện trạng thái giữ cho bạn.

Một mặt, nó giới hạn bạn ở 4Kb, điều này thực sự đủ (vì bạn thường muốn lưu trữ ID, không phải toàn bộ đối tượng), nhưng lợi ích thực sự tốt đẹp bạn nhận được là bạn không cần phải lo lắng về việc dọn dẹp phiên. Bạn để nó cho khách hàng, nơi nó thực sự nên được.


2
Trừ khi bạn tách tài nguyên tĩnh của mình ra bên ngoài đường dẫn cookie, cookie là một loại thuế cố định bạn phải trả cho mỗi yêu cầu.
Joeri Sebrechts

jQuery và Bootstrap có khoảng 150kb kết hợp và không có các thư viện khác. Cookie tối đa là 4kb và thường dưới 1Kb. Trừ khi OP hỏi về hoàn cảnh khắc nghiệt - ai quan tâm đến loại thuế đó?
Yam Marcovic

@YamMarcovic cũng có một vài vấn đề đi lên
Miro Svrtan

@MiroSvrtan Nếu bạn đang khiến người dùng của mình gửi hàng trăm yêu cầu trên mỗi trang (điều đó đã từng xảy ra ở đâu?), Tối ưu hóa rõ ràng không phải là vấn đề đối với bạn.
Yam Marcovic

Tôi đã có một khách hàng có trang web đang thực hiện ~ 170 yêu cầu HTTP để tải trang trước trước khi tư vấn cho tôi về tối ưu hóa tốc độ, vì vậy nó xảy ra, hãy tin tôi. Btw, khóa riêng / khóa chung là một khái niệm từ mật mã bất đối xứng, thường không được áp dụng trong kịch bản này khi nó tương đương với mật mã đối xứng, chỉ phức tạp hơn để thực hiện. Ngoài ra, hầu hết các triển khai lưu trữ phiên đều dựa vào một số cookie được quản lý bởi khách hàng, vì vậy lợi ích được mô tả trong đoạn cuối của câu trả lời áp dụng cho tất cả chúng.
jeteon

0

Đối với tình huống cụ thể của tôi, tôi có thể nói với bạn rằng các phiên trong cơ sở dữ liệu là nguyên nhân số một của việc treo máy chủ của chúng tôi bởi một biên độ tốt. bảng phiên của chúng tôi bị hỏng thường xuyên đến mức chúng tôi đã thực hiện để cắt nó trước.

memcache nghe có vẻ hấp dẫn, nhưng chúng ta có quá nhiều quá trình xóa toàn bộ memcache, vì vậy các phiên của người dùng sẽ bị cắt quá thường xuyên. và các phiên cũ hơn sẽ bị xóa khi bộ nhớ đã đầy ... vì vậy không còn thông tin đăng nhập vĩnh viễn.

Chúng tôi sẽ sớm thử các phiên dựa trên tệp mặc định.

Nếu bạn lo lắng về bảo mật dữ liệu phiên của mình, thì bạn không nên đưa dữ liệu đó vào phiên - và không tin tưởng vào phiên - xác thực người dùng theo mọi yêu cầu.


0

Bạn có thể cố gắng lưu phiên của bạn trên Redis . Redis nhanh như Memcached nhưng cũng có một số tùy chọn duy trì dữ liệu. Ngoài ra, các máy khách PHP khác nhau được hỗ trợ.

Ngoài ra, bạn có thể thử các dịch vụ của bên thứ 3 như Đám mây Memcached có khả năng sao chép và lưu trữ tích hợp

Tiết lộ, tôi là đồng sáng lập và CTO của dữ liệu Garantia.


2
Cảm ơn đã tiết lộ! Hãy chắc chắn rằng bạn tham gia vào trang web này ngoài các bài đăng mà bạn có thể đề cập đến các sản phẩm của riêng bạn, chúng tôi muốn bạn là người đóng góp chứ không phải công ty của bạn.
Martijn Pieters
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.