这是一个创建于 256 天前的主题，其中的信息可能已经有所发展或是发生改变。
面试的时候遇到了，实在不知道怎么回答，特来请教一下各位。
12 条回复 • 2024-04-10 15:02:46 +08:00
 |
1
RihcardLu 256 天前
依赖于经验或者看过相关的案例会好答一点，但这有个悖论，如果能提前遇见那大部分情况都能解决；遇到的基本上都是未考虑到或是考虑不完全的的。举个简单例子，比如在做一些排行榜的时候，就必然会有榜单更新的实时性、准确性、稳定性这几个因素的相互考虑。
如果要求实时性高，必然会有缓存；有缓存也必然会影响准确性，怎么及时的更新缓存；如果引入缓存、主动更新机制，系统的复杂度增加，那就又会涉及到监控（这里指的更多是业务层面监控，比如缓存更新失败如何感知），巴拉巴拉…… |
 |
2
weimutter4 256 天前
完全测试， 性能测试， 压测， 完整的监控！ 好多公司不懂微服务。 以为搞个服务就完事了。 但是正因为是微服务。 向上还要考虑服务调用。 服务依赖 ， 完整的服务监控。 等等
|
 |
3
xwwsxp 256 天前
别想了，君不见，大厂也是这个崩完那个崩，都是草班台子。
|
 |
4
uSy62nMkdH 256 天前
1L 说的很好了，这种事一般就是出一次事长一次记性，如果公司技术氛围跟体量还可以，经常会有一些故障复盘，多听听没坏处
|
 |
5
iyiluo 256 天前
做的多了就知道了，比如做一个带输入输出的接口，后面肯定会遇到 xss 攻击，所以前期一定要做好参数过滤
|
 |
6
whee 256 天前
这种事情就是经验积累的过程。听得多，遇到的多，写东西的时候就能直觉的遇见在什么样的阶段，目前这个方案会产生什么样的问题。
|
 |
7
BuffDog 256 天前
可能性是无穷的
一般都是经验问题吧，也得平衡下系统复杂度 |
 |
8
tianzx 256 天前  1
我举个例子：如何设计用户表？
可能会有问题的设计： 所有数据都丢在一张表。很明显随着数据量的增大，这里会成为 Block 系统的点 良好的设计：按照 userId or phone number 进行分库分表，然后数据聚合到 ES 或者其他系统方便进行模糊查询，最后将数据同步到 Hive 中，可以进行大数据分析。（问题：常见的分库分表算法有哪些？如何防止数据倾斜？如何保证数据一致性？如何保证数据安全？如何保证系统平滑的扩容、缩容？） 根据业务的设计：主要访问来自于 C 端还是 B 端。未来是否需要支持单点登录、第三方登录。根据业务的不同，你又可以去做针对性的优化，比如数据库的反范式，多级缓存的设计 。 最后，这只适用于面试。实际情况是：一个系统可能连 1w 个用户都没有，并发也都是个位数。 |
 |
9
hevi 256 天前
根据历史经验多想和多测吧，然后出了问题就积累，然后循环
|
 |
10
yifangtongxing28 256 天前
你能预测这些的话，直接买股票，比上班实在
|
 |
11
gosky 256 天前 via Android
预见问题的发生，应该靠经验吧？
解决潜在的问题，我的理解是只能防御潜在的问题，比如留好日志，能最快分析出问题；比如防御型编程，控制问题的影响范围 |
 |
12
KC35 256 天前
只能觉醒见闻色了
|
Select Language