面试架构篇

阿里内部框架

• nbf框架，电商
• tmf框架，高频交易系统
• 阿里面试是轻框架、重原理思想

redis

• 缓存

  • 某一台产品信息列表，取了名字key_product，key的冲突问题怎么协调，

    • 方法一：以公司业务命名
    • 方法二：用一个全局的map，这个map本身就存在redis中，把key存放到这个map中，value存描述信息

  • 缓存使用中会遇到哪些问题？

    • 一致性问题（数据库和redis）：四种解决方法，最low的是实时更新，谁修改了数据库，就要谁更新redis，第二的是定时任务更新，数据不太敏感的业务，第三个是mq第三方服务专业处理，第四种是redis的失效策略(缓存击穿和缓存雪崩)

  • redis的持久化

    • aof和rdb，两者有什么不同，rdb是某一瞬间来一个快照全量存，aof是日志方式增量存，优缺点？aof性能低，aof中有更多重复，那些中间步骤实际没有必要重复，只需要更新最新值即可，但是aof的文件相比rdb恢复要快，文件要小

互联网架构两大基石

• rpc和mq

rpc

• 理解这种请求的整个链条过程
  • 1.思想出发点？跨jvm的调用怎么实现？原有的函数指针的调用方式是实现不了的，最终是通过java的反射告诉jvm，另一台jvm要调用它哪个对象，而这些反射信息就是rpc调用的主体信息，把这个信息抽提出来，并传递过来，第二个问题就是信息传递问题？通过网络传递，这个过程涉及到序列化。同时反射信息抽提组装实际是很容易出错的，通过代理的方式封装这些数据，有很多代理方式，涉及到设计模式/jdk动态代理/源码插桩形式，

http和rpc对比优劣

• 1.http这种方式，实际是使用restful风格，有一个理念是面向资源开发，对资源的操作(crud)，同时http中有几种请求方式，post/get/put/del，把crud与请求方式对应，对于http请求，每一个url大致是http://peter/product/a001/update，ajax里面请求对应的是put操作，这种使用方式普及度非常高，在很多其他语言都是采用这种restful风格，这就给spring cloud对接其他服务带来了天然的优势，而rpc就不具备了

• 2.rpc是自己做了一个dubbo协议，如果对方不采用dubbo协议就不能使用了

• http方式通用性高但是性能低

• rpc性能高但是通用性差

• 内部调用采用rpc方式，而外部调用采用http

mq

• 几个主要的功能
  • 解耦/异步/削峰
• 你是怎么理解解耦的？
  • mq的解耦实际是借助的mq的发布订阅功能，而异步则是借助的mq的路由功能
  • mq解耦最重要带来的是开发效率的提升，比如a系统调用b系统，常规调用时必须必须保证b系统开发完成，其次必须对b系统的结构非常了解，因为a系统调用b系统的代码是写死的，两者的耦合性非常紧，通过mq解耦，服务的提供方不再关注谁调用它，它只是发布一个服务，想要调用的自己去拿
• mq非常重，要加一整套保障措施，叫MB，整个业务系统是挂载在ESB总线上，业务系统未建立前，就已经建立了ESB总线，

rabbitMq/rocketMq/kafka(一般是专业专用，一般业务不用，监控，日志分析)

• rabbit是通用型的， 功能定制的自由度比较高，
• rocket是专业型的，rabbit会配置routekey、exchange那些路由的东西，而rocket没有，比较简单，针对某些要求比较高的东西，来做一些专业性的封装，所以rabbit的性能就会差点

mq的缺点

• 丢消息，有什么办法解决吗？

  • 做回执ack的消息，如果接受方接受到消息，发一个回执给发送方，此时如果发送方迟迟没有收到消息，就会认为发送失败，就会重发，这时会出现一些矛盾的东西

    • 重试带来的问题？

      消费方重复执行，所以业务方法需要改造，接口需要满足幂等性

    • 一般怎么做幂等？

      1.让方法本身变成幂等操作，查询/id 删除/直接赋值型的update，如果update x = x+1这种，把它改造成直接赋值型的

      2.方法本身不幂等，如果是insert操作，先做查询操作，如果查询到了，直接返回，不做insert

      3.上述是针对数据库层面的，如果是其他的，比如会请求A服务中的service的f方法，我们对f方法的情况完全未知，此时可以加一个缓存层来解决，把参数做key，返回结果做value，消息消费是先查缓存中是否存在，不存在则调用，存在则直接返回

短信发送适合用mq吗（不需要返回结果的）

什么时候不适合使用mq

• 短信发送使用消息中间件适合吗？借助mq的异步功能，指不需要返回结果，实际只需要一个中转的容器就可以了，目前业界99%都是采用mysql表来作为中转容器解决
  • 把要发送内容存储到mysql的表里面，由短信系统来查询这张表来进行短信发送，这是一种业务的异步，为什么要这么做？是性能非常高，而mq是比较重的，发送失败了都不知道为什么

数据同步方案

• 非常多的框架需要信息同步

  • es/mongo
  • 主从架构需要同步，需要专门架一个mq消息总线，来保证数据同步

• 网站首页，带搜索条件的搜索框，使用频率非常高，而且还是查询操作，怎么解决高并发的问题，搜索条件太多了，缓存情况太多，导致缓存数据太多，一般这种场景会用es

• 列表展示信息称为简要信息，详情页面展示信息称为详细信息，需要5张表来组合， 直接查5张表，容易出问题，可能会宕机，假设其中搜索加上列表展示信息总共有11个字段，把mysql5张表的信息、11个字段的信息抽出来，只把11个字段放入es里面

  • 为什么es不存所有信息，只存11个字段？为了省空间
  • 如果5张表有信息变化了，怎么办？和缓存的解决方案一模一样，架一个mq消息总线，如果有商品变了，由于消息总线同时对3个系统监听，业务系统只是扔一个信息过来，这3个缓存系统自动更新

同步转异步的概念

• 同步/异步，阻塞/非阻塞
  • 同步阻塞，主线程流程，发起子线程，去进行具体的请求，主线程是需要得到子线程的结果，如果主线程在这里等待子线程返回结果就是阻塞，如果主线程不等待直接返回了，就是非阻塞，
    • 线程阻塞，但是这个线程上下文环境是被缓存的，要占用内存，如果有非常多的线程被阻塞，就会oom，这种oom占业界出现概率的80%以上，尤其是在分布式环境下，此时仅仅是由于网络抖动，服务提供方本身实际是正常的
    • 既然等可能造成oom，有没有不等，但是有结果返回回去，通过使用回调解决，比如主线程做了123步骤，调用了子线程，但是此时子线程没有返回结果，而且后面还有456步骤要执行，此时为了避免oom主线程不会等待，直线完了，而当子线程执行完会把结果推送到一个地方，会有一个监听信息，如果发现结果回来了，会拉起一个新的线程，接着把456步骤执行完

微服务

请简述一下springboot的理念

• 叫开箱即用，所有的东西都有一个默认推荐用法
  • 更高阶的用法，有定制化需求，更改默认用法，门槛更高了，

数据切片的套路—数据存储中间件

• 使用数据切片的框架
  • redis/mysql/mongo/es
• 切片带来的问题
  • 1000w数据，1台机器装不下，用了5台机器，每台机器各存了200w，但是又增加了100w，但是5台机器已经性能很慢了，所以又新加5台机器，导致原来time对应每一台机器的映射关系需要修改，假设原来time=1月的机器放在第一台，time=5月放在第四台，现在总共变成10台，所以映射关系要修改，所以有1000w的数据要修改，所以加机器的初始化过程变得很慢
  • 怎么解决上述问题？原来1000w的数据，把数据做成柱，把1000w的数据做成100个柱，每个柱上有10w数据，第一个柱子承担的是0_{10w的数据，第二个柱子承担的是10w}20W的数据，这个关系是固定的，机器数量不同时，100个柱子和机器号的对应关系，这个数据只有100条，如果修改了机器数量，之后需要修改的是这100个柱子和新的机器号的对应关系

主从选举/分布式锁方案

• 1.每个服务向桶中抛砖块

• 2.桶接到砖块之后，按入桶顺序，标号

• 3.每个服务检查自己的砖块标号是否最小，是则本机为主机，得到主导权走主机逻辑，否则为备机，走work逻辑

• 4.若A机死亡，则砖块1自动消失，此时砖块2自动获得主导权，为主机

• 5.此机制同样可以用来做分布式锁

事件驱动模式，pull与push转换

• 原来是消费方通过pull方式调用，现在业界推崇的是把pull方式改成push，运来是A调B，现在是B会自动把结果推送给A，

pull模式

• 1.当A运行时，调用B函数
  2.B运行时，调用C函数
  3.C被调用，返回值
  

• 缺点：若B或C繁忙时，整个调用链等待

push模式

• 1.C在成熟时机，将自己计算结果值存入B队列
  2.B的监听查看到队列有值，在成熟的时机，将队列中值取出，存入A的队列中
  3.A监听到队列中有值，在成熟的时机从队列中取出值，执行业务
  

• 缺点：监听的实现需要线程消耗

面试技巧

• 把简历里自己有亮点的东西，主动展示出来，如果让面试官主动提问题，结果是自己没准备的，结果大概率会黄
• 尽量不要让面试官问到自己没用过的框架，但是要把原理大概说一下，说出自己的见解，不要上来就认怂