PHP'de en güvenilir oturum depolama alanı nedir: Memcache, veritabanı veya dosyalar? [kapalı]


10

PHP oturumlarını işlemenin en iyi ve en güvenli yolu nedir? Oturumları depolamanın en iyi yolu:

  1. Veritabanı (daha güvenilir, ancak yüksek darboğaz, düşük hız, yüksek veritabanı kullanım web siteleri için iyi değil)?

  2. Memcache (süper hızlı, ancak daha fazla güvenlik sorunu dağıtılmış, sunucu yeniden başlatıldığında veri kaybetme olasılığı ve önbellek dolduğunda veri kaybetme olasılığı)?

  3. Dosyalar (varsayılan seçenek, dosya G / Ç, daha az güvenlik, vb okuma ve yazma beri yavaş sanırım).

Hangi yöntem en iyisidir? Bu yaklaşımların her birinin sorunları ve iyi şeyleri nelerdir?


2
Sadece bir makine kullanıp kullanmadığınızı veya uygulamanın dağıtıldığını belirtmeniz gerektiğine inanıyorum, çünkü bu cevapları büyük ölçüde etkileyecektir.
Arseni Mourzenko

1
@haylem Burası bu soruyu sormak için en uygun yer, onun programlama soru onun programlama kavramsal sorunu,
user1179459

3
Bu gerçekten kötü bir soru çünkü 'en iyi' sizin özel durumunuza bağlı. Facebook için 'en iyi' muhtemelen kişisel ana sayfanız için aynı 'en iyi' değildir.
GrandmasterB

1
@BrandmasterB biliyorum ki bu yüzden açıkça "Bu yaklaşımların her birinin sorunları ve iyi şeyler nelerdir?" hangisinin benim için en iyi olduğunu bulmak için.
user1179459

Yanıtlar:


6

En iyisi, diğer sorunları (önbellek boyutu, güvenlik vb.) Kolayca çözebileceğimiz için Memcached'de depolamaktır.

facebook olduğu 1. memcached tüketici. İlgileniyorsanız lütfen okuyun: http://www.facebook.com/note.php?note_id=39391378919

Diğer sorunlar nasıl çözülür?


4

Günlük uygulamaların büyük çoğunluğu için oturumları veritabanlarında tutmak iyidir. Bir sql sunucusunun işleyebileceği eşzamanlılık düzeyi ve düzeyi fazlasıyla yeterli olacaktır. Anahtar, her girişi küçük tutmak ve gereksiz satırları düzenli olarak temizlemek. Ve tabii ki uygun indeksleme.

Dosya sistemi - Bunu yapma ihtiyacını hiç görmedim. Binlerce küçük dosya yerine tablolardaki satırları yönetmenin basitliğini tercih ederim. Ayrıca, oturum istatistiklerini incelemek istiyorsanız dosyalar arasında sorgulama yapamazsınız.

PHP ile oturum işleyicilerini değiştirmek kolaydır. Böylece bir depolama biçimiyle başlayabilir ve çok fazla uğraşmadan diğerine geçebilirsiniz.


4

MEMORY depolama motorunu MySQL'de kullanmaya ne dersiniz?

Memcache kadar hızlı değildir, ancak düz SQL kullanabilmeniz avantajına sahiptir ve gerekmediğinde normal depolama motorunu kullanabilir ve kullanıcı / istek sayısı arttığında BELLEK'ye geçebilirsiniz.

Sık sık değişen bir web uygulamasında büyük miktarda istatistiksel veri depolamak için kullanıyorum, bu yüzden oturumları işlemek için kullanılmıyor, ancak bu amaç için uygun olması gerektiğini düşünüyorum.


3

Bu blog yazısı , farklı oturum depolama motorlarının Magento ile performans karşılaştırmasının sonuçlarını gösteriyor ve yaklaşık 75 eşzamanlı kullanıcıya gerçekten aralarında bir performans farkı olmadığı sonucuna varmış gibi görünüyor.

Bu seviyelerde (saniyede yaklaşık 5 işlem yaptıklarını, 12 saatlik bir süre içinde yaklaşık 430k isabet olurdu), dosya / DB / Memcache / Redis dosyalarının tümüyle işleyeceği için gördüğünüz performans sayılarına hakim olduğunu düşünüyorum. eğer düzgün kullanılırsa bir ter kırmadan trafik.

Bu, ölçeklenebilirlik, güvenilirlik ve güvenlik gibi diğer faktörleri de bırakır.

Öncelikle, bir saldırganın uygulama kodunuzu değiştirebileceği veya en azından salt okunur olsa bile anahtarları ve depolama erişim protokollerini / kimlik bilgilerini keşfedebileceği için dosya depolama alanınızdan ödün veren herhangi bir şeyin muhtemelen başka bir şeyden ödün vereceğini söylemek isterim. Giriş. Dosya depolama, düşük hacimli bir site için iyi çalışır, kurulumu kolaydır ve akıl yürütmesi kolaydır. Diske vurduğunuzda söylediğiniz kadar, bir DB okundu diski de vurur ve DB önbelleğe alabilirse, işletim sisteminiz de oturum dosyasını önbelleğe almış olacaktır. Ayrıca, bir dosya okur ve adını zaten biliyorsanız dosya sisteminize ulaşmak için mükemmeldir. PHP kullanıyorsanız, sistemin sadece uygulamanızı sunmak için kaç dosya okuması gerektiğini biliyor musunuz? Dezavantajı '

Memcache nispeten hızlıdır ve Memcache sınıfı çözümlerini daha geniş bir şekilde (Redis, vb.) Düşünüyorsanız, hız okumaları için bellek okumalarında kalıcılık vaat edecek bazı şeyler vardır, böylece her iki dünyanın da en iyisini elde edersiniz. Ayrıca, akıl yürütmeleri nispeten basittir ve oturumların anahtar / değer niteliği tam olarak bunların yapılması için tasarlanmıştır. Bunlardan birini doldurmak için ne kadar seansa girmeniz gerektiğini biliyor musunuz? Her iki durumda da, tüm seçenekleriniz kapasitelerine ulaşırsanız sizi tehlikeye atmaya zorlar. Diskler dosyalarla doldurulur (burada sayı ve boyut faktörü), önbellek depoları kapasite olarak doldurulur ve veritabanları sınırlı sayıda satıra ve dosya yaklaşımı ile aynı disk kapasitesi sınırlarına sahiptir. Ayrıca, bu sistemler yalnızca onları dağıtılmış bir şekilde çalıştırırsanız dağıtılır. Çoğu, tek bir sunucu kurulumu ile gayet iyi çalışır. Bunları dağıtırsanız, dağıtılmış sistem sorunlarınız oturum depolama seçiminizden kesinlikle görünmeyecek şekilde büyük olasılıkla zaten dağıtılmış web sunucuları / veritabanı sunucuları vb. Bununla birlikte, trafik / kapasite vb. 10 kat istediğinizde, bununla dosya depolama şemasında olduğundan çok daha doğal bir şekilde elde edilir. Bazı anahtar / değer depoları, oturum verilerinin basit analizlerini nispeten kolay bir şekilde gerçekleştirmenize izin verir, ancak çoğu SQL'in yapabileceği yere yakın bir yere ulaşmaz.

Neden veritabanının diğer seçeneklerden daha güvenilir olabileceğini önermiyorum, ancak PHP uygulamanız muhtemelen zaten kullanıyor olduğundan veritabanının cazibesini alıyorum. Bu, başka bir sunucu bağımlılığı eklemediğiniz anlamına gelir ve kullanıcı verilerini almak için oturum verilerini almak için kullandığınız aynı bağlantıyı yeniden kullanabileceğiniz anlamına gelir; böylece veriler için bir tane, Memcache vb. İçin bir tane oluşturmanız gerekmez. tablo iyi, aynı zamanda oldukça hızlı bir şekilde çalışacak ve eski oturumları birleştirmek veya oturum verilerini analiz etmek için zaten bildiğiniz oldukça basit anlambilim sağlar (neden isteyeceğinizden emin değilseniz ve bu ikisi de istemiyorsanız, muhtemelen çok önemli değil). Büyük ölçeklere ölçeklemek, Redis gibi bir şey kadar önemsiz değil,

Bence bu seçim başlangıçta çok önemli değil. Her yaklaşımın zorlukları, avantajları ve düşünmeniz gereken şeyler vardır. Genel olarak konuşursak, muhtemelen sadece PHP'nin varsayılanlarını / kullandığınız herhangi bir çerçeveyi kullanarak veya hatta en kolay olanı kullanarak uzaklaşabilirsiniz. Seçim daha sonra kötü olursa, performans analiziniz size söyleyecektir ve aldığınız trafiğin özel doğası göz önüne alındığında, uygun seçimleri yapmak için ihtiyacınız olan verilerle donanmış olacaksınız. Önde, makul olarak sahip olabileceğiniz tek şey genel spekülasyon.


0

Bu sizin ihtiyaçlarınıza bağlıdır.

Dosyalar ve veritabanı depolama alanı arasında bazı farklar vardır. Bu soruya bakın .

Ancak, Rails 3'te varsayılan olarak yapılanları yapabilir ve oturumunuz için yalnızca şifrelenmiş çerezleri kullanabilirsiniz. Böylece, tüm değerleri daha sonra şifresini çözebileceğiniz şekilde (örneğin, özel / genel anahtarlar) şifrelersiniz ve istemcinin durumu sizin için koruyarak yapmasına izin verirsiniz.

Bir yandan sizi 4Kb ile sınırlar, bu genellikle yeterlidir (genellikle tüm nesneleri değil kimlikleri saklamak istediğiniz için), ancak elde ettiğiniz gerçekten güzel bir avantaj, oturum temizleme konusunda endişelenmenize gerek olmamasıdır. Bunu gerçekten olması gereken yerde müşteriye bırakıyorsunuz .


2
Statik kaynaklarınızı çerez yolunuzun dışında olacak şekilde ayırmadığınız sürece, çerezler her istekte ödemeniz gereken sabit bir vergidir.
Joeri Sebrechts

jQuery ve Bootstrap yaklaşık 150kb'lık birleştirilmiş ve diğer kütüphaneler olmadan. Çerez maks 4kb'dir ve genellikle 1Kb'nin altındadır. OP aşırı koşullar sormadığı sürece - bu tür vergilendirmeyi kim önemsiyor?
Yam Marcovic

@YamMarcovic birkaç sorun var 1) çerezler de sunucuya gidecek (kullanıcılar genellikle daha hızlı indirme ve yükleme) gidiyor
Miro Svrtan

@MiroSvrtan Kullanıcılarınızın sayfa başına yüzlerce istek göndermesini sağlıyorsanız (bu nerede oldu?), Optimizasyon sizin için açık bir sorun değildir.
Yam Marcovic

Site, hız optimizasyonları için bana danışmadan önce ön sayfayı yüklemek için ~ 170 HTTP istekleri yapan bir müşterim vardı, bu yüzden olur, güven bana. Btw, özel / genel anahtarlar, simetrik bir şifreye eşdeğer olduğu, sadece uygulanması daha karmaşık olan bu senaryoda genellikle uygulanmayacak olan asimetrik kriptografiden bir kavramdır. Ayrıca, çoğu oturum depolama uygulaması, istemci tarafından yönetilen bir çereze dayanır, bu nedenle cevabın son paragrafında açıklanan fayda hepsi için geçerlidir.
jeteon

0

Benim özel durumum için, bir veritabanındaki oturumların iyi bir farkla sunucu kapatmamızın bir numaralı nedeni olduğunu söyleyebilirim. oturumlar tablomuz, ön-etkili olarak kısaltmak için yeterince sık bozulur.

memcache çekici görünüyor, ancak tüm memcache'i temizleyen çok fazla işlemimiz var, bu nedenle kullanıcı oturumları çok sık kesiliyordu. ve daha eski oturumlar, bellek doldukça temizlenirdi ... böylece artık kalıcı giriş yok.

Yakında varsayılan dosya tabanlı oturumları deneyeceğiz.

Oturum verilerinizin güvenliği konusunda endişeleriniz varsa, bu verileri oturuma koymamalı ve oturuma güvenmemelisiniz - kullanıcıyı her istekte doğrulayın.


0

Oturumunuzu Redis'e kaydetmeyi deneyebilirsiniz . Redis, Memcached gibi hızlıdır, ancak çeşitli veri kalıcılığı seçenekleri de vardır. Ayrıca, çeşitli PHP istemcileri desteklenir.

Ayrıca , yerleşik çoğaltma ve depolama motoru özelliklerine sahip Memcached Cloud gibi üçüncü taraf hizmetleri de deneyebilirsiniz

Açıklama, Garantia Data'nın Kurucu Ortağı ve CTO'suyum.


2
Açıklama için teşekkürler! Eğer olsa kendi ürünlerini sayabiliriz mesajların ötesinde bu sitede katılmak emin markasını yap, bizim istediğimiz sizi katkıda bulunmak için bir kişi değil, şirket olarak.
Martijn Pieters
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.