If you have a large web application running on two or more servers and you're using sessions to track users, you need to ensure that the web server serving the request has access to the user's session data.

There are two ways in doing this: sticky-sessions or shared session store.

Sticky-sessions cons:
- added load balance complexity (not so complex though)
- lower performance (traffic and visitors cannot be "balanced" between the servers)
- more stress on the load balancer (packet inspection to determine on what server to forward the request)
- when web server goes down, the sessions are lost (you can rsync the sessions to another web server if doing a planned maintenance)

Sticky-sessions pros:
- decentralized (no single point of failure)
- fast using tmpfs (tmpfs /var/lib/php5 tmpfs size=500M,atime 0 0) which can be monitored easily (it's just an mountpoint)
- simple web server implementation, no need to install anything, no configuration change
- no TCP overhead

Shared session store cons:
- single point of failure (solved with a redundancy cluster)
- added complexity (external modules, configuration, maintenance, bugs ...)
- network dependent

Shared session store pros:
- optimal web server balance
- web servers can be put offline with no session impact

PHP Session Handling with Redis
[cc lang='bash']
# web server - Ubuntu 12.04.4 LTS
\$ apt-get install make
\$ apt-get install php-pear
\$ pecl install redis

\$ cat \<\<'EOF' > /etc/php5/apache2/conf.d/redis.ini
extension=redis.so
session.save_handler = redis
session.save_path = "tcp://10.20.30.40:6379"
EOF

\$ service apache2 restart
[/cc]

It's up to you to chose the most appropriate solution :)