Yapışkan ve Yapışkan olmayan oturumlar

255

Yapışkan ve yapışkan olmayan oturumlar arasındaki farkı bilmek istiyorum. İnternetten okuduktan sonra anladıklarım:

Yapışkan : Orada sadece tek oturum nesnesi olacaktır.

Yapışkan olmayan oturum : her sunucu düğümü için oturum nesnesi

session

— Güneşli Gupta
kaynak

Yanıtlar:

613

Web siteniz yalnızca bir web sunucusu tarafından sunulduğunda, her istemci-sunucu çifti için bir oturum nesnesi oluşturulur ve web sunucusunun belleğinde kalır. İstemciden gelen tüm istekler bu web sunucusuna gider ve bu oturum nesnesini günceller. Bazı verilerin etkileşim süresi boyunca oturum nesnesinde saklanması gerekiyorsa, bu oturum nesnesinde saklanır ve oturum var olduğu sürece orada kalır.

Ancak, web sitenize bir yük dengeleyicinin arkasında oturan birden çok web sunucusu tarafından hizmet veriliyorsa, yük dengeleyici, her bir isteğin hangi gerçek (fiziksel) web sunucusuna gitmesi gerektiğine karar verir. Örneğin, yük dengeleyicinin arkasında 3 web sunucusu A, B ve C varsa, www.mywebsite.com/index.jsp adresinin A sunucusundan, www.mywebsite.com/login.jsp adresinden sunulması mümkündür. B sunucusu ve www.mywebsite.com/accoutdetails.php C sunucusundan sunulur.

Şimdi, talepler (fiziksel olarak) 3 farklı sunucudan sunuluyorsa, her sunucu sizin için bir oturum nesnesi oluşturmuştur ve bu oturum nesneleri üç bağımsız kutuda bulunduğundan, oturum nesnesinde ne olduğunu bilmenin doğrudan bir yolu yoktur. diğerinin. Bu sunucu oturumları arasında senkronize etmek için, oturum verilerini DB gibi herkes için ortak bir katmana yazmanız / okumanız gerekebilir. Şimdi bu kullanım durumu için bir db'ye / db'den veri yazmak ve okumak iyi bir fikir olmayabilir. Şimdi, yapışkan oturumun rolü geliyor .

Yük dengeleyiciye yapışkan oturumlar kullanması talimatı verilirse, diğer sunucular mevcut olsa bile tüm etkileşimleriniz aynı fiziksel sunucu ile gerçekleşir. Böylece, oturum nesneniz bu web sitesiyle olan tüm etkileşiminiz boyunca aynı olacaktır.

Özetlemek gerekirse, Yapışkan Oturumlar durumunda, tüm istekleriniz aynı fiziksel web sunucusuna yönlendirilirken, yapışkan olmayan bir yük dengeleyici durumunda isteklerinizi sunmak için herhangi bir web sunucusu seçebilir.

Örnek olarak, Amazon'un Elastik Yük Dengeleyicisi ve yapışkan oturumları burada okuyabilirsiniz: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html

— TJ-
kaynak

@ TJ- Bir düğüm kullanılamayacaksa ne olur?

— gstackoverflow

Çoğu durumda, oturum kaybedilecektir. Durumunda AWS ESB bir örneği başarısız veya sağlıksız hale gelirse, yük dengeleyici yerine mevcut yük dengeleme algoritması dayalı yeni sağlıklı örneğini seçer o örneğe isteği yönlendirme durur. Yük dengeleyici, oturumu şimdi yeni sağlıklı örneğe "yapışmış" gibi davranır ve başarısız örnek geri gelse bile istekleri bu örneğe yönlendirmeye devam eder.

— TJ-

LoadBalancer hangi bilgilere göre bir HTTP oturumu yapışkan yapar? Özellikle HTTPS bağlantılarında bu sorun ilginç hale gelir. LB'yi, SSL bağlantısını kesip HTTP oturumunu alabilmesi için web sunucularının özel anahtarıyla mı besliyorsunuz? Yoksa LB sadece istemci IP adresini kullanıyor mu? Bu durumda, birden çok istemcinin aynı IP adresini kullandığı proxy sunucusu ne olacak? Ya da daha da kötüsü, IP adresinin sık sık değiştiği mobil istemciler? Yoksa bunun için daha iyi bir teknik var mı? Teşekkürler

— g000ze

Evet, kesinlikle haklısın. Bu bağlamda "x-forwarded-for" başlığını veya bir yapışkan çerezi kullanmak için SSL Sonlandırmasının kullanılması ve bu nedenle isteğin LB'de şifresinin çözülmesi gerekir.

— TJ-

@ g000ze Doğrudan İnternet'e sunulmayan uygulamalarla uğraşırken, TLS'yi yalnızca en dış proxy sunucusunda etkinleştirmenin yaygın olduğuna inanıyorum. (Yük dengeleyici, belki de basit bir şekilde, isteği birden çok sunucunun herhangi birine aktarabilecek özel bir proxy sunucusu türü olarak görülebilir.) Yük dengeleyici ile diğer sunucular arasındaki trafik yerel, güvenli bir ağda gerçekleşir ve bu nedenle şifrelenmesi genellikle gerekli değildir veya şifrelenmesi gerekiyorsa, kendinden imzalı bir sertifika yeterli olabilir (proxy buna güvenecek şekilde yapılandırılabileceğinden).

— jpmc26

106

Burada daha fazla ayrıntıyla bir cevap verdim: https://stackoverflow.com/a/11045462/592477

Veya orada okuyabilirsiniz ==>

Yük dengelemeyi kullandığınızda, birçok tomcat örneğiniz olduğu ve yükleri bölmeniz gerektiği anlamına gelir.

Yapışkan oturum olmadan oturum çoğaltmayı kullanıyorsanız: Web uygulamanızı kullanan yalnızca bir kullanıcınız olduğunu ve 3 tomcat örneğiniz olduğunu düşünün. Bu kullanıcı uygulamanıza birkaç istek gönderir, ardından yük dengeleyici bu isteklerden bazılarını ilk tomcat örneğine gönderir ve bu isteklerin bir kısmını ikinci örneğe, diğerini de üçüncü örneğe gönderir.
Yapışkan oturumu çoğaltmadan kullanıyorsanız:Web uygulamanızı kullanan yalnızca bir kullanıcınız olduğunu ve 3 tomcat örneğiniz olduğunu düşünün. Bu kullanıcı uygulamanıza birkaç istek gönderir, ardından yük dengeleyici ilk kullanıcı isteğini üç tomcat örneğinden birine gönderir ve bu kullanıcı tarafından oturumu sırasında gönderilen diğer tüm istekler aynı tomcat örneğine gönderilir. Bu istekler sırasında, bu tomcat örneğini (kullanılan tomcat örneği) kapatır veya yeniden başlatırsanız, loadbalancer kalan istekleri hala çalışan bir tomcat örneğine gönderir, ancak oturum çoğaltmasını kullanmadığınız için AMA, tomcat örneği kalan istekler kullanıcı oturumunun bir kopyasına sahip değilse bu tomcat için kullanıcı bir oturum başlatır: kullanıcı oturumu kaybeder ve web uygulaması hala çalışıyor olmasına rağmen web uygulamasından bağlantısı kesilir.
Oturum çoğaltma İLE yapışkan oturum kullanıyorsanız:Web uygulamanızı kullanan yalnızca bir kullanıcınız olduğunu ve 3 tomcat örneğiniz olduğunu düşünün. Bu kullanıcı uygulamanıza birkaç istek gönderir, ardından yük dengeleyici ilk kullanıcı isteğini üç tomcat örneğinden birine gönderir ve bu kullanıcı tarafından oturumu sırasında gönderilen diğer tüm istekler aynı tomcat örneğine gönderilir. Bu istekler sırasında, bu tomcat örneğini kapatır veya yeniden başlatırsanız (kullanılan tomcat örneği) loadbalancer, oturum çoğaltmayı kullandıkça kalan istekleri hala çalışan bir diğer tomcat örneğine gönderir, kalan istekleri alan tomcat örneği kullanıcı oturumunun bir kopyası daha sonra kullanıcı oturumuna devam eder: kullanıcı bağlantıyı kesmeden web uygulamanıza göz atmaya devam eder, tomcat örneğinin kapatılması kullanıcı gezinmesini etkilemez.

— Nico
kaynak

Hmm .. bunu okurken merak ediyorum: dördüncü bir seçenek olması mantıklı olmaz mıydı: Yapışkan olmayan oturum çoğaltma İLE? Ya da farklı bir şekilde söyleyin: eğer oturum yine de farklı örneklere çoğaltılırsa yapışkan bir oturum yapmanın avantajı nedir? Yani, oturumları örnekler arasında çoğaltıyorsanız, isteği herhangi bir sunucuya da iletebilirsiniz, değil mi? Neyi kaçırıyorum?

— dingalapadum

@dingalapadum haklısınız, teorik olarak yapışkan oturum olmadan oturum çoğaltması yapabilirsiniz. Ancak büyük bir küme durumunda ağ performansı için kötüdür. Daha sonra tomcat'te böyle bir oturumla oturum çoğaltmayı kullanmanın bazı stratejileri vardır ( tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html ) yapışkan bir oturum ve sadece bir çoğaltma (burada bir düğüm) tüm düğüm oturumu çoğaltmasını tutan yedekleme yöneticisi olarak adlandırılır).

— Nico

Daha sonra yapışkan oturum, büyük kümede en iyi olan yalnızca bir oturum çoğaltmasına sahip olmanızı sağlar.

— Nico

Ah anlıyorum - Doğru anlarsam, tüm oturumları çoğaltmak kümeyi dahili olarak dolduracak demektir - sorunu görüyorum. Oh, ve şimdi cevabına daha yakından baktığımda, gördüm ki, bu aslında ilk tarif ettiğin durum ... 'duh' ..

— dingalapadum

@dingalapadum sorunuza cevap geliştirmek için izin verir hoş geldiniz

— Nico