这是一个创建于 786 天前的主题，其中的信息可能已经有所发展或是发生改变。
对外部接口依赖进行降级，百度到的相关实践是用 ehcache （本地内存）来缓存外部接口返回的数据，如果外部服务挂了，就从缓存里面取，但是 ehcache 是应用级别的缓存，一个应用可能有多个副本，这种情况下他们之间的缓存并不共享，比如有用户 A 的数据可能存在应用副本 1 上，那么当进行降级的时候，如果请求落在副本 2 上，那么这个好时候就取不到缓存，还是一样会报错，如果应用的副本数很多，那这种情况会更加明显。 为了解决上述问题，是不是应该引入 redis 这种分布式缓存呢？但是 redis 也是一个外部依赖，所以 redis 并不可靠，其次，如果多个应用都针对同一个外部依赖接口来进行降级，那么这个时候 redis 的 qps 会成倍的增长，对 redis 本身而言也是一个不小的负担
针对上述，需要如何进行考量来选择合适的缓存策略对接口依赖进行降级
 |
1
themostlazyman 2022-09-16 13:07:48 +08:00
不清楚什么业务场景需要缓存，你说的场景可以缓存到客户端吗？
|
 |
2
LoremIpSum OP @themostlazyman 举个例子，服务端身份验证
|
|
3
themostlazyman 2022-09-16 13:19:27 +08:00
@LoremIpSum 登录，服务端不控制登录个数的话，不注销的话，可以存 jwt 。存 session 的话，可以 nginx ，iphash ，但考虑 ip 会变得话，也是不很推荐。不知道你并发多高，单机 redis 据说可以 10w ，超过这个可以考虑 redis 分片，我使用的就是 jwt 加 redis 验证。
|
|
4
LoremIpSum OP @themostlazyman 我是调用接口去验证的，我是怕接口挂了，得做降级，如果降级的话就得缓存接口数据，那么就是我上面提到的问题
|
 |
5
garyox64 2022-09-16 13:37:21 +08:00
大部分登陆应该都是用 redis 做的，redis 很顶的可以放心用
如果本来就是降级方案，就没必要考虑 再降级了吧 正常逻辑应该都是默认查 redis 失败了用接口回源吧 |
 |
6
laozhoubuluo 2022-09-16 14:02:19 +08:00
1. 如果需要分布式缓存的话，肯定是最好引入 Redis 的，不比自己实现差。
2. 可以对 Redis 做集群实现缓存层高可用，但也得清楚没有绝对可靠的方式。 3. 一般推荐方式是不管外部接口状态如何，超时时间内都在 Redis 取数据，超时了就重新拉接口弄数据放进 Redis 。这样一方面是降低了接口服务的负载，另外如果突然短期故障 Redis 里面有足够支撑一段时间的数据。但是超时多久就需要结合业务来做平衡了，超时时间长了前端修改了配置后端不能读到最新数据（除非上游接口在数据变化的时候能通知给您），超时时间短了可能接口挂一两分钟所有的缓存就没了。 |
|
7
LoremIpSum OP @laozhoubuluo 我是要增对外部接口来降级，默认是调用外部接口，如果外部接口不可用，才用缓存数据来处理
|
|
8
laozhoubuluo 2022-09-16 14:27:38 +08:00
@LoremIpSum 那就只要拿到了外部接口的数据就设置超时放进 Redis 就能实现。
|
 |
9
johnnyleaf 2022-09-16 16:16:53 +08:00
集群服务的依赖一定来自外部，可以不考虑操作内存。世界上没有 100%可用的玩意。所以不用追求极致的可靠。一层保一层后，最终保障系统稳定的东西一定是人来即时响应系统出现的问题。所以你可以信任 redis-cluster 。顺便坐好系统告警。
|
 |
10
lingly02 2022-09-16 17:00:13 +08:00
1. redis 用来作为缓存降级是可行的。而且如果只是用来降级，那集群都不一定要上，配置下合理的持久化策略。外部接口和 redis 同时出故障的机率应该很小。
2.redis 的 QPS 一般来说肯定大于你外部接口的 QPS 。如果你外部接口能撑住，那 redis 就应该没问题。 |
 |
11
jorneyr 2022-09-16 17:05:54 +08:00
EhCache 也支持分布式。
|
Select Language