faq

1、我们通过负载均衡来分担服务器的压力。当设备使用 MQTT 协议与接入层服务器，也就是 MQTT Broker 服务器通信，不同的设备发送的相同 Topic 的消息就会发送到不同的服务器上。如果有订阅者订阅这个 Topic 消息，那么应该怎么保证订阅者可以接收到所有的设备发送的此 Topic 的消息呢？

2、你可以先想象一个场景，我们想利用全世界的个人电脑、手机、平板上的空闲存储空间，构成一个可以付费共享的分布式文件系统，希望用户可以安装一个 App 在自己的个人设备上，将个人资料安全地存储到这个分布式文件系统中，并支付一定费用；用户也可以用这个 App 将自己设备上的空闲存储空间共享出去，成为这个分布式文件系统存储的一部分，并收取一定费用。我想问你的是，如果是你来设计这个分布式文件系统，你是怎么思考的？你的设计方案是什么？

3、下图是腾讯的大数据平台架构，请你尝试对这个架构图的主要组件和运行机制进行分析。

4、哪些数据中台建设的方法论和支撑技术是适合你当前的公司的，如果你们要做数据中台，你所在的组织架构要做哪些变动。

5、在一个企业的指标字典中，你觉得应该原子指标多，还是派生指标多？原因是什么呢

6、你公司的数据库有什么瓶颈吗，你计划对它做什么样的改造呢？

7、除了高延迟的流处理这一缺点外，你认为 Spark 还有什么不足？可以怎样改进？

内存问题： JVM 中 overheader 开销很大，在数据规模很大的场景中，靠内存处理的开销很大。如果内存不够把中间结果写入硬盘的话，又会影响处理速度；
由于 GC 机制的问题，在处理大量数据时会出现性能不稳定
在流处理中，不是真正的流式，微批次处理，存在些许延时

8、为什么 Kubernetes 要求 externalIPs 必须是至少能够路由到一个 Kubernetes 的节点

当用户向指定的主机和端口发起请求的时候会把请求转发到k8s由集群中的Pod对用户的请求进行响应

9、如果我的需求是，当访问www.mysite.com和 forums.mysite.com时，分别访问到不同的 Service（比如：site-svc 和 forums-svc）。那么，这个 Ingress 该如何定义呢？请你描述出 YAML 文件中的 rules 字段。

# < 1.19
...
  rules:
    - host: www.mysite.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              serviceName: site-svc
              servicePort: 80
    - host: forums.mysite.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              serviceName: forums-svc
              servicePort: 80
# >= 1.19.x
...
  rules:
    - host: www.mysite.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: site-svc
                port: 
                  number: 80
    - host: forums.mysite.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: 
                name: forums-svc
                port:
                  number: 80              

10、你在企业中实施 DevOps 时，遇到过什么问题吗？你是怎么解决这个问题的呢？你是否走过一些弯路呢？

11、结合实际工作谈一谈你在面对突发的流量冲击的时候是如何制定预案的呢？

12、有什么方法可以快速定位到 SQL 语句慢的问题

13、你认为什么时候引入分库分表是合适的？是数据库性能不够的时候就开始分库分表么？

分库主要解决的是并发量大的问题。因为并发量一旦上来了，那么数据库就可能会成为瓶颈，因为数据库的连接数是有限的，虽然可以调整，但是也不是无限调整的。
所以，当你的数据库的读或者写的QPS过高，导致你的数据库连接数不足了的时候，就需要考虑分库了，通过增加数据库实例的方式来提供更多的可用数据库链接，从而提升系统的并发度

分表其实主要解决的是数据量大的问题。
假如你的单表数据量非常大，因为并发不高，数据量连接可能还够，但是存储和查询的性能遇到了瓶颈了，你做了很多优化之后还是无法提升效率的时候，就需要考虑做分表了

那么什么时候分库又分表呢，那就是既需要解决并发量大的问题，又需要解决数据量大的问题时候。通常情况下，高并发和数据量大的问题都是同时发生的，所以，我们会经常遇到分库分表需要同时进行的情况。
所以，当你的数据库链接也不够了，并且单表数据量也很大导致查询比较慢的时候，就需要做既分库又分表了

14、我们在启动应用的时候，使用的地址格式为“:8080”，其实这里也可以为“localhost:8080”、“127.0.0.1:8080”或者“10.11.22.33:8080”（10.11.22.33 为本机绑定的 IP）。你了解 localhost、127.0.0.1、10.11.22.33 以及不填写 IP 的区别么？

localhost 是个域名 , 默认将localhost指向 127.0.0.1
127.0.0.1 回环地址 loopback 是一个特殊的网络接口(可理解成虚拟网卡)，用于本机中各个应用之间的网络交互 , 这个地址在其他计算机上不能访问
与具体的网络接口绑定的 , 可供其他设备访问到
监听本机中所有IP的端口

15、消息队列模型中，消费者是主动去消息队列获取消息的，而消息队列需要保证多个消费者可以获取到消息，也就是说一个消费者获取消息后并不会删除该消息，那么如何保证同一个消息不被同一个消费者重复消费呢？

每次保存数据前，先查询下，不存在就插入, 这种是并发不高的情况下可以使用
添加唯一约束条件
已经消费的消息，把消息id插入到消息表里面

16、什么是CAP理论？

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

17、根据 Job 控制器的工作原理，如果你定义的 parallelism 比 completions 还大的话，比如： 1 parallelism: 4 2 completions: 2 那么，这个 Job 最开始创建的时候，会同时启动几个 Pod 呢？原因是什么？

需要创建的 Pod 数目 = 最终需要的 Pod 数目 - 实际在 Running 状态 Pod 数目 - 已经成功退出的 Pod 数目 = 2 - 0 - 0 = 2
而parallelism数量为4，2小于4，所以应该会创建2个

18、你在实践中使用过消息队列吗？它主要帮你解决了哪些问题？

实现异步
缓解大数据流的冲击
服务解耦

19、请问，当日志量很大的时候，直接将日志输出到容器 stdout 和 stderr 上，有没有什么隐患呢？有没有解决办法呢

容器会一直写日志，导致磁盘爆满，影响系统应用
收集容器的标准输出，当日志量过大时会导致Docker Daemon 成为日志收集的瓶颈，日志的收集速度受限
日志文件量过大时，利用docker logs -f 查看时会直接将Docker Daemon阻塞住，造成docker ps等命令也不响应

fluentd/filebeat 日志转发到远端的elsticSearch
当容器日志只能输出某些文件的时候，我们可以通过一个sidecar容器把这些日志文件，重新输出到sidecar的stdout和stderr上
通过一个sidecar的容器，直接把应用的日志发送到远程存储里

20、现在中台很热，我们经常听到很多中台名词，它们分别是什么定位呢？

业务中台：电商业务中常见的业务会包含支付中心、商品中心、订单中心、会员中心等
技术中台：消息队列、技术框架、容器云、Devops平台
数据中台：数据建模、日志分析、用户画像
算法中台：推荐算法、图像识别、语音识别、搜索算法

（狭义的）业务中台：一般指在线业务为典型特征的中台。在OLDI（Online Data-Intensive）时代，越来越多的企业的核心业务都是在线业务，因此把在线业务中台简称为业务中台。但对那些不是以在线业务为主的企业，它需要的业务中台可能就不是在线业务中台了，而是数据中台或别的什么中台。
数据中台：一般指以数据采集、数据集成、数据治理，指标体系和数据仓库统一建设等数据管理活动为典型特征的中台。同样，在OLDI时代，数据中台越来越重要。狭义的业务中台也就是在线业务中台负责OLDI中的OL（Online），数据中台负责OLDI中的DI（Data-Intensive）。
用户中台：用户中台可以认为是一种特殊的数据中台，一般以用户ID统一、全域用户画像建设、全域会员体系建设等为典型特征。用户中台很通用，比更广义的数据中台往往更常见。很多企业没能力建设更全面的数据中台，但建设了会员中心等用户中台。
内容中台：内容中台往往也可以认为是一种特殊的数据中台，一般以内容的采买、内容爬取、内容的加工处理、内容安全保障等为典型特征。
搜索推荐中台：这两个中台比较像，因为搜索和推荐的技术比较相似。这两个中台一般是为推荐和搜索系统提供一套相对标准的工作流程，同时支持流程各环节的可定制能力，从而支持多个前端推荐搜索业务的快速开发。