搭第三方桥, 万万不可.

分享创造 / 270 / 11 / 创建于 5个月前

小项目没必要搭第三方桥,别试途在项目中穿插redis, python, hook等功能. 这跟代码无关, 代码写得很爽, 但后期维护极其复杂.
大项目更要小心, 一般每个桥的负责人都不一样, 要搭在一起, 是需要协调的.

这是php代码错了?, 还是redis错了呢?

redis python HOOK

核心优势, php

tuesdays

20 声望

核心优势, php

0 人点赞

推荐文章：

更多推荐...

博客

PHP高并发商品秒杀问题的 2大种（MySQL or Redis）解决方案 10 / 1 |

博客

Redis 分布式锁 17 / 5 |

博客

PHP+Redis 有序集合实现 24 小时排行榜实时更新 11 / 3 |

博客

面试总结 —— Redis “缓存穿透”、“缓存击穿”、“缓存雪崩” 20 / 12 |

博客

Redis 基础学习 35 / 6 |

讨论数量: 11

qufo

Laravel 8.x 译者 302 声望

当然是 redis 错了，如果是 PHP 的话你不会在这里抱怨。

5个月前评论

tuesdays （楼主）

为什么不是php写错了, 当redis无法访问时, 应该兼容, 走备用方案. ??

Alone88

@tuesdays 这也不是写错的问题吧，没做容灾不就这样

tuesdays （楼主）

@Alone88 那就来了, redis的人说php容灾, php的人说redis容灾. 责任到底归谁?

Alone88

容灾不都是DB?

qufo （作者）

@tuesdays 这么说下去就永无止境了，当redis无法访问时, 应该兼容, 走备用方案A，备用方案A无效时走备用方案B，备用方案B无效时走备用方案C，什么时候是个头？谁能保证备案方案Z一定可行？要不要走备用方案AA？

Imuyu

课程读者 871 声望

这是个灰色地带，首先redis没有保证高可用，至少没有主从切换，其次调用方没有调用降级，属于各打50打板，不过一般没有高可用的需求，这种情况很常见~

5个月前评论

tuesdays （楼主）

所以我一直说, 能少用第三方件, 就少用, 避免维护压力.

Imuyu （作者）

@tuesdays 思路对，也不对，如果一味的采用自有方案来满足，系统可能越来越臃肿，当你意识到需要第三方服务来配合的时候，系统可能就要动大手术了

qufo

Laravel 8.x 译者 302 声望

@tuesdays 的方案是说 小项目 少用第三方。 大项目 谨慎用第三方。这样是对的。小项目你也不会考虑第三方，自己做个个人网站用什么 redis 嘛。一个企业站上什么 kafka 嘛。大项目的话就不一样了。

5个月前评论

浮心

课程读者 62 声望

引入新东西没什么问题，问题是：是否投入了足够的资源（人力、时间等），而不是出了问题再开始找锅。如果出现既要又要的情况，那就啥也要不到

5个月前评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容，与人为善，比聪明更重要！

帮助

搭第三方桥, 万万不可.

推荐文章：

社区赞助商

关于 LearnKu

资源推荐

服务提供商

其他信息

搭第三方桥, 万万不可.

推荐文章：

社区赞助商

关于 LearnKu

资源推荐

服务提供商

其他信息

请登录