我有一堆关于ssl，本地会话和负载平衡的问题，这些问题似乎是相互关联的，所以我对这个问题的长度提前道歉。
我有一个使用基于文件的会话的网站。 网站的性质大部分是http，但有些章节是ssl。 目前，由于基于文件的会话，任何ssl请求都必须与之前的任何http请求相同的服务器。
由于时间的限制，我想做最简单的事情来负载平衡增加http和sslstream量。
粘性负载均衡algorithm似乎有两个选项：
基于IP的解决scheme可能会工作，但哈希algorithm可能会改变服务器，当服务器宕机或添加这是当前基于文件的会话设置不可取的服务器。 我还假设用户在浏览网站时合法地更改ips在技术上是可行的。
基于cookie的algorithm似乎更好，但是当sslencryption时无法检查cookie看起来呈现出自己的问题。
我一直在search如何负载平衡ssl的例子，我似乎无法find任何明确的例子，可以做基于cookie的负载平衡，并可以通过增加另一个ssl解码器来处理增加ssl负载的设置。
我见过的大多数显式示例都有位于浏览器客户端和负载平衡器之间的ssl解码器（通常是硬件，apache_mod_ssl或nginx）。 这些例子通常看起来像这样（从http://haproxy.1wt.eu/download/1.3/doc/architecture.txt中修改）：
192.168.1.1 192.168.1.11-192.168.1.14
------- + ----------- + ----- + ----- + ----- +
| | | | |
+ - + - + + - + - + + - + - + + - + - + + - + - +
| LB1 | | A | | B | | C | | D |
+ ----- + + --- + + --- + + --- + + --- +
Apache 4廉价的Web服务器
了mod_ssl
HAProxy的
上例中的ssl解码部分似乎是一个不可横向扩展的潜在瓶颈。
我看了haproxy，它似乎有一个'模式tcp'选项，将允许这样的事情，这将允许您有多个ssl解码器：
HAProxy的
|
-------------
| |
ssl-decoder-1 ssl-decoder2
| |
-------------------
| | |
web1 web2 web3
但是，在这样的设置中，看起来你会失去客户端ip，因为haproxy不解码ssl： https ://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forward -对于
我也看了nginx，也没有看到水平可伸缩ssl解码器的任何明确的例子。 似乎有很多人将nginx作为潜在的瓶颈。 至less这个链接似乎表明，nginx甚至没有类似haproxy的设置的选项，你会失去ip说nginx“不支持透明地传递TCP连接到后端” 如何通过Apache SSLstream量槽nginx代理？ 。
问题：
假设我所说的一切都是真的，这些似乎是我的select：
“最简单的事情”，就是转移到一个集中的会话存储。 你必须用负载平衡器，haproxy，SSL和其余部分设置所有这些pipe道，当我看到的每一个会话处理代码都使得插入不同的存储引擎变得非常微不足道，所以一点点的代码和非常less的额外的复杂性解决了所有的问题。
womble是正确的共享会话存储让事情变得更容易。 除了他的回答之外，我还可以在这个问题的负载平衡部分展开一些工作：
为什么似乎没有更多的设置例子添加更多的ssl解码器来处理增加的stream量？
现代多核PC可以每秒处理几千个 SSL事务。 如果这成为瓶颈，那么F5 ，思杰，思科等专用设备可能会更快。 所以大多数网站永远不会超出一个良好的单设备SSL和负载平衡解决scheme。
假设我所说的一切都是真的，这些似乎是我的select：
如果您需要，可以select水平扩展SSL解密。
常用的方法是使用DNS Round Robin来获得高可用的SSL加速器对，即为域发布多个IP地址，每个IP地址指向一对SSL加速器。
在这种情况下，您可能会担心在用户会话中间发生DNS TTL超时，将用户激活到另一个应用程序服务器。 这不应该是一个普遍的现象，但可能会发生。 共享会话存储是常见的解决scheme，但可以通过其他方式进行处理。
作为一个例子，您可以将SSL解密从应用程序服务器平衡中分离出来。 SSL处理比基本的负载平衡更占用CPU资源，因此单个负载平衡器应该能够饱和一对SSL加速器。 喜欢这个：
Internet --> DNS round robin to multiple SSL accelerators --> plain HTTP to a single HTTP load balancer --> plain HTTP to multiple application servers
正如开头提到的那样，共享会话存储简化了很多事情，几乎可以肯定是一个更好的长期解决scheme，而不是在SSL /负载平衡层中添加很多复杂性。
当产品进化时，回答这样的2年老问题很有意思。 现在，haproxy支持PROXY协议，即使在纯TCP模式下，它也可以将客户端的IP传递到下一跳。 它还支持本地SSL，以及SSL粘性，如果您想将其用作SSL场（可能由haproxy服务器生成）之前的第一层。 所以看起来你的请求提前一点，实现已经赶上了:-)
我同意在这里的womble和Jesper。 最简单/最好的路线是修复代码。 当然，作为系统pipe理员，我们往往没有这个select，但即使在这种情况下，也有足够的技巧可以使相对便宜的现代硬件足够大，即使不是真正的水平。
我只是想发表评论，你在担心失去客户端IP。 在任何主要的L7 /代理解决scheme中，您都可以在请求中插入X-Forwarded-For（或任何您想要的）标题。 然后，在接收请求的后端Web服务器上，您可以更改日志文件格式，以将该值logging在用于logginglayer3客户端IP的文件的相同空间中。 这样，任何日志分析软件没有看到差异（当你尾巴）。
我们没有足够的权限来了解你的设置，但是对于你不可能出错的ha-proxy，nginx和varnish三人来说，移动你的负载平衡到代理层工具。 这将解决您的ssl问题，并为您提供一系列新选项，如caching，内容切换和标题操作。
一些随意的想法;）
首先，拍摄决定使用基于文件的会话数据的人。 从文件系统读取/写入数据将不会比仅仅回到源代码来获取所需的数据要快。 这是关于它的最糟糕的方式。
我个人从来没有见过将数据存储在会话中的情况比根据需要直接从数据库中提取数据更好。 也就是说，我已经看到了使用memcache或类似的caching策略可以帮助一个网站扩展到数百万用户，但是这与使用会话不同。
其次，您刚刚发现不使用会话的头号理由：负载均衡。 仅供参考 – Sticky并不意味着卡住了。 即使启用了“粘滞会话”，您仍然可以在用户使用应用程序的过程中将用户切换到另一台服务器上。 这将发生在最不合时宜的时刻。 粘滞只是意味着负载平衡器将尝试将用户推回到他们开始的服务器，但这绝不是一个保证。
这一点通常会导致人们将会话存储回数据库…我认为这是一个彻底的失败 。 对于会话来说，它必须被加载并写在每个页面请求上。 当它存储在一个数据库中（对于负载均衡服务器来说是必需的），这需要两个服务器查询：第一个获取数据，第二个写入任何更新。
失败的一部分是，人们通常使用会话，所以他们不必回到数据库拉像用户的名字…但是，如果页面必须查询数据库加载会话，那么…好吧，你应该能够看到这里的逻辑问题。
只有会话更糟…因为页面处理器必须在页面生命周期结束时将会话数据写回数据库。 这意味着，而不是一个查询拉用户名，你最终有两个。 为每一个单页面加载。 此外，它意味着序列化和反序列化具有自身性能影响的数据。
我的观点是：会话是邪恶的，没有它你通常会变得更好。 低stream量的站点只能运行在一个Web服务器上，不需要可能发生的性能提升; 而且在networking农场上运行的高stream量网站在缩放方面也受到限制。
不要在前面使用Haproxy，您可以使用循环DNS在多个SSL解码器之间进行粗略的平衡，然后将其传递给haproxy进行正确的负载平衡。