DistributedCacheEntryOptions的三个过期属性如何使用？

三个属性的具体作用如下：

• AbsoluteExpiration：DateTimeOffset?类型的绝对过期时间，直接指定缓存条目到期的固定时间点，无论期间该条目是否被访问，到点就会被清理。
• AbsoluteExpirationRelativeToNow：TimeSpan?类型的相对当前时间的绝对过期时间，使用时框架会自动以当前时间 + 该时间间隔计算出最终的AbsoluteExpiration，本质和直接设置AbsoluteExpiration一致，仅为了简化编码，例如要设置1天后过期可以直接传TimeSpan.FromDays(1)，无需手动计算时间点。
• SlidingExpiration：TimeSpan?类型的滑动过期时间，规则为缓存条目每被成功访问一次，过期时间就会向后顺延该时间间隔。例如设置20分钟滑动过期，用户10点首次访问后过期时间为10:20，若10:15再次访问，过期时间就会顺延到10:35，只要用户在过期前有访问，缓存就会持续生效。

三个属性并非互斥，可以同时赋值多个，生效规则如下：

• 若同时设置了AbsoluteExpiration和AbsoluteExpirationRelativeToNow，会以两者计算出的更早的过期时间为准，常规使用时二选一即可，无需同时设置。
• 若同时设置了滑动过期和任意一种绝对过期，绝对过期是最高优先级的硬上限，哪怕滑动过期持续被访问顺延，到了绝对过期的时间点，缓存条目一定会被删除。例如设置20分钟滑动过期+2小时绝对过期，即使用户每10分钟访问一次，缓存最长也只会留存2小时，不会无限顺延。
• 若三个属性都未赋值，缓存条目默认永久有效，仅会在主动删除、服务端重启/资源清理时被移除。

你在基于gRPC实现会话状态客户端时，可以参考以下处理逻辑：

1. 客户端侧先把AbsoluteExpirationRelativeToNow转换为最终的绝对时间戳再传给gRPC服务端，不要直接传递时间间隔，避免客户端与服务端时间不一致导致的过期逻辑异常。
2. 服务端存储缓存条目时，需要同时记录最终绝对过期时间、滑动过期间隔（如有设置）两个核心字段。
3. 每次处理Get请求命中缓存时，如果该条目配置了滑动过期，需要将其过期时间更新为当前时间 + 滑动过期间隔，但更新后的过期时间不能超过初始设置的绝对过期时间。

内容的提问来源于stack exchange，提问作者Léster