如果是同时更新redis和数据库的话实际就是缓存更新策略问题吧。说说我的看法咯，算抛砖引玉吧：
这类问题常用两种策略：
1.写缓存时更新：这是指DB写成功以后就更新缓存。这种策略能减少穿透，但容易引起数据的不一致。
2.读缓存时更新：这是指DB写成功以后只删除缓存，等到需要读取时再重建缓存。这种策略一致性可以保证，但穿透大，容易给DB造成压力。

（搜了一下发现缓存更新的模式有很多，上面说的两种只是我所知
1.Write-through 立即写
2.Write-behind 后写 先写缓存，将写事件放入Queue，再写数据库
3. Eviction Policies 驱逐策略 缓存更新策略 直接删除缓存中数据，等下次读取时更新。
4. Replication 复制
5. Peer-To-Peer (P2P)
）

如果是只更新redis再异步更新到数据库的话缓存宕机后数据不好重建，如果你的数据不需要严格准确但需要访问迅速的话倒是可以考虑这样玩，比如页面访问人数之类。

redis-fdw没用过。