เซสชัน Sticky และ Non-Sticky

ฉันต้องการทราบความแตกต่างระหว่างเซสชันที่เหนียวและไม่เหนียว สิ่งที่ฉันเข้าใจหลังจากอ่านจากอินเทอร์เน็ต:

Sticky : มีเพียงวัตถุเซสชันเดียวเท่านั้นที่จะอยู่ที่นั่น

Non-sticky session : session object สำหรับแต่ละโหนดเซิร์ฟเวอร์

เมื่อเว็บไซต์ของคุณให้บริการโดยเว็บเซิร์ฟเวอร์เดียวเท่านั้นสำหรับแต่ละคู่ไคลเอนต์ - เซิร์ฟเวอร์วัตถุเซสชันจะถูกสร้างขึ้นและยังคงอยู่ในหน่วยความจำของเว็บเซิร์ฟเวอร์ คำขอทั้งหมดจากลูกค้าไปที่เว็บเซิร์ฟเวอร์นี้และอัปเดตวัตถุเซสชันนี้ หากข้อมูลบางอย่างจำเป็นต้องเก็บไว้ในวัตถุเซสชั่นในช่วงเวลาของการโต้ตอบมันจะถูกเก็บไว้ในวัตถุเซสชั่นนี้และอยู่ที่นั่นตราบเท่าที่มีอยู่เซสชั่น

อย่างไรก็ตามหากเว็บไซต์ของคุณให้บริการโดยเว็บเซิร์ฟเวอร์หลายตัวที่อยู่ด้านหลังตัวโหลดบาลานซ์ตัวโหลดบาลานซ์จะตัดสินใจว่าควรจะไปที่เว็บเซิร์ฟเวอร์จริง (ทางกายภาพ) หรือไม่ ตัวอย่างเช่นหากมี 3 เว็บเซิร์ฟเวอร์ A, B และ C ด้านหลังตัวโหลดบาลานซ์อาจเป็นไปได้ว่า www.mywebsite.com/index.jsp ให้บริการจากเซิร์ฟเวอร์ A, www.mywebsite.com/login.jsp ให้บริการจาก เซิร์ฟเวอร์ B และ www.mywebsite.com/accoutdetails.php ให้บริการจากเซิร์ฟเวอร์ C

ทีนี้ถ้าคำขอถูกให้บริการจาก (เซิร์ฟเวอร์) 3 เซิร์ฟเวอร์ที่แตกต่างกันแต่ละเซิร์ฟเวอร์ได้สร้างวัตถุเซสชันสำหรับคุณและเนื่องจากวัตถุเซสชันเหล่านี้นั่งอยู่บนกล่องสามกล่องที่เป็นอิสระไม่มีทางโดยตรงที่จะรู้ว่ามีอะไรในวัตถุเซสชัน ของอื่น ๆ ในการซิงโครไนซ์ระหว่างเซสชันเซิร์ฟเวอร์เหล่านี้คุณอาจต้องเขียน / อ่านข้อมูลเซสชันลงในเลเยอร์ซึ่งเป็นเรื่องธรรมดาสำหรับทุกคน - เช่นเดียวกับฐานข้อมูล ตอนนี้การเขียนและอ่านข้อมูลไปยัง / จากฐานข้อมูลสำหรับกรณีการใช้งานนี้อาจไม่ใช่ความคิดที่ดี ตอนนี้ที่นี่บทบาทของเหนียว - เซสชันมา

ถ้าตัวโหลดบาลานซ์ได้รับคำแนะนำให้ใช้เซสชั่นปักหมุดการโต้ตอบทั้งหมดของคุณจะเกิดขึ้นกับฟิสิคัลเซิร์ฟเวอร์เดียวกันแม้ว่าเซิร์ฟเวอร์อื่นจะมีอยู่ก็ตาม ดังนั้นวัตถุเซสชันของคุณจะเหมือนกันตลอดการโต้ตอบกับเว็บไซต์นี้

เพื่อสรุปในกรณีของ Sticky Sessions คำขอทั้งหมดของคุณจะถูกนำไปยังเว็บเซิร์ฟเวอร์เดียวกันในขณะที่ในกรณีที่ loadbalancer ไม่เหนียวเหนอะหนะอาจเลือกเว็บเซิร์ฟเวอร์ใด ๆ เพื่อตอบสนองคำขอของคุณ

ตัวอย่างเช่นคุณอาจอ่านเกี่ยวกับ Elastic Load Balancer และเซสชันเหนียวของ Amazon ได้ที่นี่: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html

ฉันได้รับคำตอบพร้อมรายละเอียดเพิ่มเติมที่นี่: https://stackoverflow.com/a/11045462/592477

หรือคุณสามารถอ่านได้ที่นั่น ==>

เมื่อคุณใช้การปรับสมดุลการโหลดหมายถึงคุณมี Tomcat หลายอินสแตนซ์และคุณต้องแบ่งโหลด

• หากคุณกำลังใช้การเรพลิเคทเซสชันโดยไม่ใช้เซสชั่นเหนียว:ลองนึกภาพว่าคุณมีผู้ใช้เพียงคนเดียวที่ใช้แอปพลิเคชันเว็บของคุณและคุณมีอินสแตนซ์ Tomcat 3 ตัว ผู้ใช้นี้ส่งการร้องขอหลายครั้งไปยังแอปของคุณจากนั้นตัวโหลดบาลานซ์จะส่งการร้องขอเหล่านี้ไปยังอินสแตนซ์ tomcat แรกและส่งคำขออื่น ๆ เหล่านี้ไปยังอินสแตนซ์ที่สองและอื่น ๆ ที่สาม
• หากคุณใช้เซสชั่นเหนียวโดยไม่มีการจำลองแบบ:ลองนึกภาพคุณมีผู้ใช้เพียงคนเดียวที่ใช้แอปพลิเคชันบนเว็บของคุณและคุณมีอินสแตนซ์ Tomcat 3 ตัว ผู้ใช้นี้ส่งคำขอหลายครั้งไปยังแอปของคุณจากนั้น loadbalancer จะส่งคำขอผู้ใช้ครั้งแรกไปยังหนึ่งในสามกรณี Tomcat และคำขออื่น ๆ ทั้งหมดที่ส่งโดยผู้ใช้รายนี้ในระหว่างเซสชันของเขาจะถูกส่งไปยังอินสแตนซ์ Tomcat เดียวกัน ในระหว่างการร้องขอเหล่านี้หากคุณปิดหรือรีสตาร์ทอินสแตนซ์ tomcat นี้ (อินสแตนซ์ tomcat ที่ใช้) loadbalancer ส่งการร้องขอที่เหลือไปยังอินสแตนซ์ tomcat อื่น ๆ ที่ยังคงทำงานอยู่ แต่คุณไม่ได้ใช้การจำลองแบบเซสชัน คำขอที่เหลือไม่มีสำเนาของเซสชันผู้ใช้สำหรับ Tomcat นี้ผู้ใช้เริ่มเซสชัน: ผู้ใช้ทำเซสชันของเขาหลวมและถูกตัดการเชื่อมต่อจากเว็บแอปแม้ว่าเว็บแอปจะยังทำงานอยู่
• หากคุณใช้เซสชั่นเหนียวกับการจำลองเซสชัน:ลองนึกภาพคุณมีผู้ใช้เพียงคนเดียวที่ใช้แอปพลิเคชันบนเว็บของคุณและคุณมีอินสแตนซ์ Tomcat 3 ตัว ผู้ใช้นี้ส่งคำขอหลายครั้งไปยังแอปของคุณจากนั้น loadbalancer จะส่งคำขอผู้ใช้ครั้งแรกไปยังหนึ่งในสามกรณี Tomcat และคำขออื่น ๆ ทั้งหมดที่ส่งโดยผู้ใช้รายนี้ในระหว่างเซสชันของเขาจะถูกส่งไปยังอินสแตนซ์ Tomcat เดียวกัน ในระหว่างการร้องขอเหล่านี้หากคุณปิดเครื่องหรือเริ่มต้นอินสแตนซ์ tomcat (อินสแตนซ์ tomcat ที่ใช้) loadbalancer จะส่งการร้องขอที่เหลือไปยังอินสแตนซ์ tomcat อื่นที่ยังคงทำงานอยู่ในขณะที่คุณใช้การจำลองแบบเซสชัน สำเนาของเซสชันผู้ใช้จากนั้นผู้ใช้ยังคงอยู่ในเซสชันของเขา: ผู้ใช้ยังคงเรียกดูแอปพลิเคชันเว็บของคุณโดยไม่ถูกตัดการเชื่อมต่อการปิดอินสแตนซ์ tomcat ไม่ส่งผลกระทบต่อการนำทางของผู้ใช้