HCL Commerce的版本9为电子商务企业提供了许多巨大的好处。其优点之一是其云原生架构，允许动态可伸缩性并提高部署的速度和敏捷性。仍在使用旧版本产品的客户争相升级也就不足为奇了。转换到最新版本并非没有挑战。由于Commerce服务器的容器化和无状态模型，一些客户不得不重构他们的代码，不再使用HTTP Session对象。为了支持这一变化，HCL引入了Redis，一种开源服务，允许容器共享缓存和Redis缓存中的其他会话对象。
V9中的HTTP会话问题
在HCL Commerce V7和V8中，应用程序能够在HTTP会话对象中保存与用户会话相关的数据，方法是利用会话关联，或者跨集群中的节点启用会话复制。
V9版本的HTTP会话问题
由于HCL Commerce V9中使用了无状态容器，应用程序不再支持会话关联或复制。例如，如果您在container1上的HTTP会话中存储了一个对象，而您的下一个请求命中了container2，那么版本9中的container2将无法使用该会话信息。
Redis解决方案
HCL已经认识到这一挑战，并引入了Redis，这是HCL Commerce V9中引入的集中式内存数据库。通过将Redis与HCL Cache结合使用，Perficient能够重构现有的解决方案，以利用数据缓存，这些数据缓存可以远程存储在Redis中，并在Kubernates集群中的所有pod中共享。然后HCL Cache处理缓存和失效，以允许应用程序的业务逻辑保持不变，只更改会话信息的存储机制。
在V9.1中解决HTTP会话问题的高级步骤
- 创建自定义对象缓存:可以使用engine命令创建自定义对象缓存。
- Redis:将对象缓存配置为远程，因为所有pod都需要访问相同的对象缓存。这将确保，无论您从一个pod中更改了什么，当来自其他pod的请求时，都会立即反映出来。
- 序列化:由于对象存储在JVM之外，因此需要对对象进行序列化。
- 替换HTTP Session代码，使用InitialContext根据对象的JNDI名称查找缓存，并使用Redis缓存进行存储。
根据业务需求，还可以将数据缓存配置为本地、远程或两者兼备。在“both”配置中，当需要缓存一个条目时，HCL Cache将首先检查它是否已经缓存在当前节点的本地JVM中。如果它找到了条目，它将缓存的条目返回给请求，否则，它将检查Redis中的远程缓存中的条目。当缓存条目需要失效时，HCL Commerce向Redis发送失效消息，由Redis处理该消息。条目的HCL缓存将首先从本地缓存清除，然后从远程缓存清除。
在决定如何配置缓存时，考虑业务因素是很重要的。您想知道数据更改的频率，以及是否需要跨应用程序节点共享数据。由于延迟，您不希望经常访问远程缓存，但是设置和使缓存失效也会带来开销，因此了解业务使用非常重要。本地缓存是最快的，因为它驻留在JVM中，但仅限于节点。远程缓存较慢，但对所有节点都可用。通常，如果数据经常更改，则应该将其加载到远程缓存中以供共享使用。如果它是相当静态的数据，那么本地可能更有意义，可以像注册表一样对待。“both”设置提供了两个世界的最好结果，但在使缓存信息无效时有开销。好消息是，当业务环境发生变化时，可以相当容易地更改配置。
复述,限制
Redis的限制之一是它不支持不活动特性，即在最后一次缓存命中后，将缓存条目保留在缓存中的时间。解决此问题的一种方法是为缓存设置一个静态超时时间，以便在超时之后自动删除缓存条目。所面临的挑战是选择一个合理的超时值，使其足够长，以便站点上的用户完成其活动。
Redis也没有最近最少使用(Least Recently Used, LRU)的缓存算法来决定在缓存耗尽存储空间时从缓存中删除哪些条目。解决这个问题的一个方法是将内存设置得足够大，并以一种不太可能耗尽内存的方式设置超时配置。当缓存过期时，Redis从内存中清理实际的缓存条目，然后HCL cache运行一个后台任务，清理指向过期条目的所有依赖项。
