华为一面

    • 项目的设计构思？
    • 项目是怎么运行的？
    • 说一下对分布式的理解？
    • 多线程的实操经验
    • 集合Collection类

    没搞懂的问题：

    • 幂等
    • event - common
    • 项目部署：项目部署到了什么平台？平台技术是什么？

    面试准备问题：
    对自己项目的介绍：
    我当时所负责的这个项目是一个在线教育平台，搭建架构的时候主要是根据 DDD 来进行规划的。因为后台的架构设计是根据 DDD 思想将整个后台分为了数个微服务板块，所以为了统一管理不同的微服务板块，我们在中间加入了一层网关。那么整个项目中的主要板块有内容管理，是用来负责网站的教师课程等内容的增删改查功能；在线视频点播板块，在这里我们嵌合了阿里云的视频点播功能；会员管理板块，主要负责会员的注册登陆等的功能。在项目底层我们使用的是 mysql 数据库，持久层用的 mybatis-plus 框架来进行数据库的操作。

    项目中所用到的技术

    • Mybatis & Mybatis-plus
    • swagger
    • aliyun oss 对象储存
    • aliyun vod 视频点播
    • EasyExcel
    • Spring Cloud

    在项目开发过程中遇到的问题

    • concurrancy (并发)
      • 并发是指：数个线程同时在一个 cpu 上运行，这些线程轮流获得 cpu 的使用权，但任意一个时间点上都只有一个线程获得 cpu 的使用权并且在运行，而同时的其他线程则处于挂起的状态
      • 并发带来的问题：线程不安全
      • 并发问题的解决方案：使用 synchronized 关键字修饰涉及到的方法或者代码块，那么被修饰的方法或者代码块在任意时刻就只能有一个线程在使用
    • 缓存
      • 在项目中我们也有用到缓存，我们当时是通过将数据储存在 redis 中来实现的。项目中用到缓存的地方主要是会员注册时的验证码以及网站首页一些数据的存放。例如首页滚动条上用到的宣传图案地址，将这个数据放到缓存里面去主要是考虑到了这个图案更换的频率比较低，一般只有在有新活动出来或者新课程上线的时候才会有更新，而已对于所有用户他们看到的宣传图案都是一样的，所以就将这个数据放到了缓存来减少数据库的读取负担。
    • 幂等
      • 幂等是指：多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致
    • 读写分离
      • 使用读写分离的原因：
        • 读写量很大，为了提高数据库读写性能，所以进行读写分离
        • 日常运行写少读多，所以配置一个主库处理数据写入，多个从库进行数据读取
      • 读写分离的现实
        • 一般是 Master / Slave 模式，Master 库 (主库) 负责处理数据库写入请求，而 Slave 库 (从库) 负责读取请求。主库将变更写入 binlog 日志，然后从库连接到主库之后，从库有一个 IO 线程，将主库的 binlog 日志拷贝到自己本地，写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog，然后执行 binlog 日志中的内容，也就是在自己本地再次执行一遍 SQL，这样就可以保证自己跟主库的数据是一样的。
        • 存在问题：1）从库从主库的日志拷贝记录再在本地执行 SQL，中间会有延时的出现；2）如果主库突然宕机，但是从库还没有讲记录负责到本地，那么就会造成主从库数据不一样；应对方法：半同步复制 & 并行复制
    • event - common

    项目部署

    • 版本管理：我们当时项目是将项目上传到 gitee 去进行版本管理的
    • CICD用到了什么工具：我们的这个项目是在服务器上使用 Jenkins 进行 CICD
    • 部署到了什么平台？
    • 平台技术是什么？

    项目管理

    • 瀑布式开发
      • 基本流程：需求 -> 设计 -> 开发 -> 测试
      • 特点：1）阶段分明；2）环环相扣，上一阶段的输出就是下一个阶段的输入，直至整个开发流程完成；3）强调文档管理；4）开发周期时间长
    • 敏捷开发模式
      • 基本流程：整个开发流程分为多次迭代 (Sprint)，需求、设计、编码、测试、上线都必须在一个迭代中完成，每个迭代的目标都是产生一个可上线的软件
      • meetings:
        • 待办事项整理会议：分析用户场景，团队交流找出场景中要实现的技术任务
        • 迭代计划会议：明确产品功能列表 (backlog)，估算所需工作量，分配开发任务
        • 每日站会：每日汇报工作进度；昨天完成内容，今天计划内容，有无需要帮助的地方
        • 评审会：展示迭代工作结果
        • 反思会：迭代之后总结
    • 敏捷开发和瀑布式开发的区别？
      • 瀑布式开发以文档为主，根据文档来，需求比较明确；敏捷式主要是围绕 backlog list 来进行开发？(不过 backlog list 跟文档之间的区别是什么…？)
      • 在敏捷式开发中每次迭代都能让客户看到效果，不过在瀑布式中只有当产品最终发布了才能让客户看到

    Some points:
    命名规范：

    • 好的命名能起到注解的作用，要让别人看到命名就知道那个类、变量、方法是用来干嘛的
    • 类使用 UpperCamelCase 风格，但 DO /BO / DTO /VO / AO 除外
    • 方法名、参数名、成员变量、局部变量统一使用 lowerCamelCase 风格
    • 常量命名使用蛇形命名
    • 抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾
    • 包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式

    RESTful API

    • REST -> Resource (资源) Representational (表现形式) -> REpresentational State Transfer (状态转移)；API -> application programming interface
    • Resource：指真实的对象数据，每一个资源都有特定的 URI 与之对应，我们通过访问 URI 来获得资源
    • Representational：”资源” 是一种信息实体，但其可以有多种表达形式，REST 中常见的文件传递形式有 json 和 xml
    • State Transfer：指 URI 同时带有描述服务器端资源状态的动词 -> GET，POST，PUT，DELETE
    • 路径 (URL) 命名中一般建议只使用名词，由 HTTP 动词来表达进行何种操作

    CAP 理论

    • Consistency，一致性，指所有节点访问同一份最新的数据副本
    • Availability，可用性，非故障的节点在合理的时间内返回合理的响应
    • Partition Tolerance，分区容错性，分布式系统出现网络分区时，仍然能提供对外服务
      • 网络分区：分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫网络分区
    • CAP 理论是指，当发生了网络分区的时候，如果我们要继续维持服务的话，那么强一致性和可用性两者间就只能二选一
      • AP 架构，即使大部分节点挂掉也不会影响服务，不过节点上的数据可能不是最新的
      • CP 架构，不保证每次请求都能正常返回结果，但保证返回结果的一致性
      • Zookeeper 支持 CP，Eureka 支持 AP，Nacos 同时支持两种架构

    为什么java 程序的开头是main方法？
    java权限修饰词 - https://blog.csdn.net/zw1996/article/details/53240155
    线程：