继续问一个面试题：针对海量数据、巨量访问（千万级别），并且需要保证实时性、稳定性、安全性的情况下，你需要做这么一个系统，说说你的架构思路？

[coolair]

据我了解，该公司的项目系统业务量，百分之百不会超过 1000 并发，百分之八十不会超过 200 并发。

我在心里回了句：不知道贵司什么业务能够达到这种级别，我非常希望进入公司学习成长，发光发热。

顺便请教下各位，有没有专门对这种“造火箭”的技术进行讲解的八股文博客或者书籍？！最近面的几个小公司都是问些这玩意。

[murmur]

这个题我真的不知道怎么解，因为阿里在双十一，第一件事就是停掉了往期消费记录的查询功能，这种又大又冷的数据，在高并发的时候就是个累赘。

海量数据+大并发+实时+稳定，如果这些数据还不能负载均衡拆开，插眼等大佬

[gotounix]

参考 12306 当年大神们给的建议。

参考各市健康码崩溃时大神们给的建议。

[night98]

起步花一千万招一批大佬来搞，包括但不限于数据库，应用层，缓存层的大佬，再花 2000 万招业务开发，后续按每月五千万的薪资预算来迭代

[murmur]

@gotounix 12306 的例子互联网公司学不来

首先，12306 挂钩我国铁路建设，只要高铁车次够多，就不需要抢，而互联网很多抢购是耍猴，根本没有货
其次，12306 对流量不关心，他只关心票卖了多少，所以 12306 的官方排队绝杀灰产
第三，12306 现在是分时段放票、抢票，这样并发就分散下去了

[fishCatcher]

逻辑层搞成无状态，负载均衡+加机器就可以搞定，主要瓶颈在存储。
存储想要达到高可用+强一致是不可能的。
高可用存储比如类 redis kv ，极端情况下可能出现主从短期不一致。强一致存储，例如基于 raft 的 kv ，可用性又差了一些。所以具体该用哪些、怎么用，完全取决于业务的特性和容忍度。比如推广搜可能对一致性要求就低一些，而电商就要求强一致但是速度不用特别快。
如果面试官非要抛开业务谈架构的话，那他大概率也是个面经选手。

[sujin190]

（说起来这个问题没有具体场景毫无意义，所以具体问问贵司啥场景啥业务做到了也是合情合理吧，看起来我是在膜拜大神其实我是在嘲讽你们就是个只会瞎意淫的弱鸡。。）

不知道这个地方的千万级别是 pv 还是并发，千万并发实际情况纯属瞎想，通用场景下会真的出现这种么？会出现的都是像秒杀、iot 这种场景明确的，12306 大概也和秒杀的场景差不多，千万 pv 的话需要啥优化，都 2022 年了多搞几台机器就是了，所以这个问题问的本身就没啥意义没啥用吧

[dengshen]

把 app 跑在天河一号上就行。单机版 /doge

[p2pCoder]

系统设计的核心是 trade off
所以，第一件事，就要抛弃掉某些特性
后端设计的核心还是存储和计算，存储选型和计算逻辑是核心
《数据密集型应用系统设计》是最合适的入门的书，其他就是直接看具体设计按例，事务性系统我很少涉及，非事务系统 推荐常规的 feed 流系统设计 push 系统设计 推荐广告引擎设计 搜索引擎设计等，这些网上的博客都不少，有国内外大厂的技术博客。
github repo 推荐 https://github.com/donnemartin/system-design-primer

[liprais]

千万级数据量 pgsql 随便玩了
千万级并发啥都不好使

[caiji11]

你面的啥岗位 问的这么模糊

[opengps]

说简单也简单，把系统设计成压力分散的模式即可，控制单台服务器最大压力并发不超过 10 ，剩下的就是堆服务器数量了

[documentzhangx66]

@murmur 这种说法纯 sx ，12306 的本质问题在于运力不够，这与互联网抢购耍猴是一回事。其次如果 12306 只关心卖票情况，就不会出现很多空车情况。

[murmur]

@documentzhangx66 不看回答的么，我第一句写的就是高铁次数够多

抢购是因为流量也是一门生意，尤其是淘宝这种，管你是爬虫还是用户，对于淘宝都是收商家广告展示费

12306 改了官方补票之后，以前手动按 F5 的少了，自动抢票的机器人废了，那自然恶意流量下来，就能留给正常业务

[murmur]

淘宝的例子不恰当，请无视，换个例子，应该是把抢购改成实名预约制，而且比如你买个 iphone ，背后就印着你的名字，杜绝倒卖

当然这根本不可能，但是火车票可以，火车票是实名制，你退票了，人家立刻把票分给其他排队的

[binux]

面试不是做题。
问题模糊？不清楚具体场景？你不会问啊！
你问什么问题，怎么问问题的就是面试的内容。而不是给出一个答案就完事了。

[haah]

难道不是从买服务器开始么？