swzxsyh

--笔记

0%

发表于 更新于

Volatile

volatile的中文意思是不稳定的、易变的，用volatile修饰的变量是为了保证变量的可见性。

  • Volatile作用：用来确保将变量的更新操作通知到其他线程

  • 原理：

    1）编译器会注意到被volatile修饰的变量是共享的，因此不会将该变量上的操作与其他内存操作一起重新排序

    volatile变量不会被缓存在寄存器中，因此读取volatile变量总会返回最新的值

    2）在访问volatile变量时，不会执行加锁操作，因此也不会阻塞线程，对非volatile变量进行读写时，每个线程先从内存拷贝变量到CPU缓存中

    总结：不会重排、不会缓存（永远是最新值）、不会加锁（因此不会阻塞）

阅读全文 »

发表于 更新于

DDD与中台、微服务的关系

  • 什么是中台
  • 企业中台组成
  • 基于DDD的微服务设计
  • 微服务拆分和设计原则
  • 中台、微服务与DDD的关系
阅读全文 »

发表于 更新于

AQS

介绍：

  • 用途：是并发包的一个基础组件，用来实现各种锁，各种同步组件。ReentrantLock就是用AQS实现的

    比如，Semaphore用它来表现剩余的许可数，ReentrantLock用它来表现拥有它的线程已经请求了多少次锁；FutureTask用它来表现任务的状态等。

    使用 AQS 来实现一个同步器需要覆盖实现如下几个方法，并且使用getState、setState和compareAndSetState这三个方法来操作状态。

  • AQS全称：AbstractQueuedSynchrinizer，抽象队列同步器。

阅读全文 »

发表于 更新于

mysql主从复制原理：

1.从库生成两个线程，一个IO线程一个SQL线程

2.IO线程会去请求主库binlog，并将得到的binlog写到本地的relay-log（中继日志）文件中

3.主库会生成一个log dump线程，用来给从库IO线程传送binlog

4.SQL线程会读取relay-log文件中的日志，并解析成SQL逐一执行

发表于 更新于

一、分库分表

  • 分库场景：如果数据库的查询QPS过高，就要考虑拆库，比如：查询QPS为3500，假设单库可以支撑1000个连接数，那么就考虑拆分成4个库，来分散查询压力。

  • 分库分表场景：

    切分方案 解决的问题
    只分库不分表 数据库读/写 QPS过高，数据库连接数不足
    只分表不分库 单表数据量过大，存储性能遇到瓶颈
    既分库又分表 连接数不足+存储性能遇到瓶颈

二、数据切分方法

  • 水平切分

    这是一种按业务维度切分的方式，比如，常见的按会员维度进行切分，根据一定规则，把不同会员的数据散落在不同的库表中。

  • 垂直切分

    垂直切分可以理解为：把一张表的不同字段拆分到不同的表中

三 分库分表后会遇到哪些坑

  • 事务一致性

    解决办法：XA协议、两阶段提交、TCC，通常使用最终一致性的方案，采用事务补偿的方式

  • 分页、排序问题

    1）如果排序字段恰好是分片字段，通过分片规则就可以定位到分片的位置；如果排序字段是非分片字段，就需要在不同的分片点中将数据进行排序再返回；然后不同分片的数据汇集到一起再进行汇总和排序，最终返回给用户。

    2）用ES

  • 全局唯一主键问题

    分布式id生产方案

四 分库分表后历史数据如何做迁移

一般采用【双写】的方式进行迁移

1.增量的消息往新表和老表各写一份

2.将旧表的数据迁移至新库

3.迟早新表的数据会赶上旧表的数据

4.校验新表数据和老表数据是否对得上

5.开启双读（一部分流量走新表，一部分流量走老表），相当于灰度的过程

6.读流量全部切换至新表，停止旧表的写入

7.提前准备回滚机制，临时切换失败能恢复正常业务以及修复数据的相关程序

五 分库分表中间件对比

Sharding-jdbc：client层方案

  • 优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高（轻便，维护成本低，比较推荐中小型公司项目使用）

  • 缺点：如果遇到升级，各个系统都需要重新升级版本再发布，各个系统都需要耦合Sharding-jdbc的依赖

Mycat：proxy层方案

  • 缺点： 需要部署，自己要运维一套中间件，运维成本高
  • 优点：对于各个项目都是透明的，如果遇到升级问题，自己中间件搞定就行了（推荐大型公司项目使用）。

发表于 更新于

MySQL-堆排序查询慢

问题：

根据主键排序，获取一条时，查询异常缓慢，测试260万数据需2.8s-3s

如果根据唯一键排序，则需要6s

原因：

由于MySQL 5.6的 priority queue ，在5.7 出现问题：

1
ORDER BY id DESC LIMIT 1

此问题应仅发生在MySQL 5.7版本 ORDERBY 排序 配合 LIMIT 1 使用时发生。测试分页以及批量暂未发生相同异常

解决方案：

  • 使用FORCE INDEX 可修复部分问题，但需针对性加索引

    1
    2
    3
    4
    5
    6
    7
    -- 强制使用索引
    EXPLAIN 
    SELECT * FROM	`table_name` 
    FORCE INDEX (`index_name`)
    WHERE	(`conditions`) 
    ORDER BY `id` DESC
    LIMIT 1;

  • 根据 主键 && 唯一键 排序, 全表条件查询可缩短至0.3s,增加条件筛选可在0.03左右查询结束

    ORDER BY id,code DESC LIMIT 1

具体原因:

https://blog.csdn.net/wolfchenxing/article/details/88947577

发表于 更新于

为什么使用MQ

  • 解耦
  • 异步
  • 削峰

MQ选型

Kafka：追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务，大型公司建议可以选用，如果有日志采集功能，肯定是首选 Kafka。

RocketMQ：天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。

RocketMQ 在稳定性上可能更值得信赖，这些业务场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择 RocketMQ。

RabbitMQ：结合 erlang 语言本身的并发优势，性能较好，社区活跃度也比较高，但是不利于做二次开发和维护，不过 RabbitMQ 的社区十分活跃，可以解决开发过程中遇到的 bug。如果你的数据量没有那么大，小公司优先选择功能比较完备的 RabbitMQ。

ActiveMQ：官方社区现在对 ActiveMQ 5.x 维护越来越少，较少在大规模吞吐的场景中使用。

阅读全文 »

发表于 更新于

通用问题

JAVA

  • 提问走向 – 优点、缺点、匹配点

    • 各自优缺点，项目为何选用某一种

      • List

        ArrayList、LinkedList

      • Map

        HashMap、LinkedHshMap、TreeMap、ConcurrentHashMap

      • JUC

      • GC

SQL

  • CURD
    • 多次Create
      • 幂等性
    • 批量Delete
      • 如何删除大量数据，分批次？另起Job删？
    • 并发Update
      • 保证变更顺序，避免对账异常
    • 海量Require
      • 索引相关

Middleware

Register

MQ

  • 各自优缺点、为何选型

Cache

Config

Job

RPC

  • 集群、分布式特性
    • 集群
    • 分布式
      • CAP
      • 不同Middleware复合CAP中的哪一部分，以及优缺点

SpringBoot如何与中间件集成

DesignPattern

  • Spring、Middleware使用哪些设计模式

  • 是否Singleton

    • 配置类一般是Singleton

  • 是否线程安全

业务问题

业务量

  • UV – 独立访问量

  • PV

  • QPS

    • 每小时最大UV / 3600 = QPS

  • TPS

  • 访问量激增时如何搭建高并发系统

    • 页面缓存
    • Nginx Cache
    • Load Balance
    • Server Cache
    • 读写DB
    • 分库分表

链路

  • 上下游
  • 优化、重构
    • 读多写少、写多读少
    • 实时性要求

难点

  • 思路
  • 影响力
来源：

https://www.bilibili.com/video/BV1KU4y1L7JA

https://github.com/alibaba/spring-cloud-alibaba/issues/1909

发表于 更新于

G1

G1垃圾收集器简介

Garbage First(简称:G1)收集器是垃圾收集器技术发展历史上的一个里程碑,它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式.

G1是一款主要面向服务端应用的垃圾收集器,HotSpot开发团队赋予它的期望是未来可以替换掉JDK5中发布的CMS收集器. JDK9发布之日,G1宣布取代了Parallel Scavenge加Parallel Old的组合,成为服务端模式下默认的垃圾收集器,而CMS则被声明为(Deprecate)使用的收集器.

G1收集器兼顾低延迟和高吞吐在服务端运行,HotSpot团队期望取代CMS收集器。也就是在满足停顿时间的情况下获取最大的吞度量。有两种收集模式Young GC和Mixed GC。G1收集器将堆内存划分成大小相等的Region,新生代,老年代也就成了逻辑概念。整体上采用的是标记-整理算法,局部采用了复制算法。

G1实现了可控停顿时间的垃圾收集器,通过-XX:MaxGCPauseMillis参数进行设置，默认是200ms。

G1是jdk1.9的默认垃圾收集器,-XX:+UseG1GC开启

image

阅读全文 »