xiaozhigang

kafka保证消息不丢失

发表于 2023-11-13 分类于中间件

简述

在kafka的使用过程中，消息传递有下图三个步骤，消息的丢失也就在这三个步骤中：发送过程中丢失、同步过程中丢失、拉取过程中丢失。

发送过程中丢失

发送方式

生产者的发送方式有三种：

1、简单发送，不关心发送结果，所以发送失败消息丢失也不知道。

ProducerRecord<String,String> record = new ProducerRecord<>("topicName","key","value");
try{
   //这里只是把消息放进了一个缓冲区中，然后使用单独的线程将消息发送到服务端
   producer.send(record);
}
catch(Exception){
   e.printStackTrace();
}

2、同步发送，等待发送返回

ProducerRecord<String,String> record = new ProducerRecord<>("topicName","key","value");
try{
   //send方法返回的是Future<RecordMetaData> 对象，然后我们可以调用get()方法等待响应
   Future<RecordMetaData> future = producer.send(record); 
   future.get();
}
catch(Exception){
   e.printStackTrace();
}

3、异步发送，执行回调方法

private class DemoProducerCallback implements Callback{
   @override
   public void onCompletion(RecordMetadata recordMetadata,Exception e){
       //发生错误的回调方法,可以写入日志，或写入DB通过其它线程重重试，保证最终的数据送达
   }
}
ProducerRecord<String,String> record = new ProducerRecord<>("topicName","key","value");
producer.send(record，new DemoProducerCallback()))

在这三种发送方法中，第一种方法，无返回，不感知，所以也无法保证消息不丢失。所以要保证消息不丢失，只能选择第二种或者第三种，一般情况下更推荐第三种。

acks参数设置

在生产者中有acks参数，该参数指定了kafka的多少个副本同步后才算消息发送成功。该参数取值范围：

1、acks=0，表示生产者在消息后不管有没有在leader磁盘上落盘，就认为消息发送成功。

2、acks=1，表示生产者在消息后，在leader磁盘上落盘，就认为消息发送成功，不管其他follower有没有同步。

3、acks=all，表示生产者在消息后，在leader磁盘上落盘，其他follower都同步落盘，认为消息发送成功。

小结

通过设置发送方式和acks参数，可以保证在发送方式中不丢失，甚至acks参数都可以保证后面的同步过程中消息不丢失。

发送方式一般设置为异步发送，acks参数默认设置为1。

同步过程中丢失

在同步过程中，除了上面说的答acks参数，还有其他副本机制保证消息不丢失。避免leader节点的崩溃导致消息的丢失。

broker中的配置项,unclean.leader.election.enable = false，表示不允许非ISR中的副本被选举为首领，以免数据丢失。

ISR：是指与leader保持一定程度（这种范围是可通过参数进行配置的）同步的副本和 leader 共同被称为ISR

OSR：与leader同步时，滞后很多的副本（不包括leader）被称为OSR

AR，分区中所有的副本统称为AR。AR = ISR + OSR

拉取过程中丢失

设置 enable.auto.commit = false，在consumer端消费消息操作完成以后再手动提交 offset，类似于下文中的代码示例

public void consumerMsg(){
    while(true){
        //这里的poll(100)指的是kafka server端没有消息时，连接等待的时间，超过该时间立即返回空给consumer
        ConsumerRecords<String,String> records = consomer.poll(100);
        for(ConsumerRecord<String,String> record : records){
            // 这里是消费消息的逻辑（简单逻辑输入到控制台）
            System.out.printIn(record.value));
            //提交偏移量
            try{
                consumer.commitSync();  //同步提交 如果异步的话，可以使用 consumer.commitAsync();
            }
            catch(CommitFailedException ex){
                log.error("commit fail");
            }
        }
    }
}

可复用jar包能力架构

发表于 2023-10-28 分类于 JAVA

需求描述

计划将原有的代码抽取成可复用的原子能力jar包，一个业务可能需要调用多个原子能力jar包，jar包调用链配置在配置文件中。

实现外部调用接口，通过原子能力调用链实现原子能力包调用。

主要目的：1、实现能力抽取复用，2、实现原子能力编排。

1、没有架构的架构

外部业务通过接口调用service服务，service服务内部通过配置文件调用封装好的jar包。kafka作为消息中间件，为service和运行的jar收集日志。

redis作为缓存中间件，为service和运行的jar提供缓存服务，而MySQL为为service和运行的jar提供持久化数据存储。

2、抽取engine服务

所有的逻辑都杂糅在service服务内，很明显不合适，如果需要扩展多节点的化，那整个service服务都要部署扩展。

其实扩展多节点，主要是为了可复用的jar包能在多节点运行，提高运行效率。

那么我们抽取出一个engine服务，只做加载运行jar包，这样扩展多节点的话，只要扩展engine服务就行。

在抽取完之后，engine和service就不是一个服务了，service调用engine可以通过http请求，但是engine还得向service返回心跳。最好的就是通过kafka来实现这个心跳检测。

3、拆分service

为了提高可拓展性，我们抽出了engine服务，现在的service其实还负责两件事，第一个就是对外的接口暴露，第二个就是内部原子能力的调度。

现在为了使职责更内敛，我们将service再次拆分，拆分成：getaway和schedule

4、新增注册中心

现在又多了getaway和schedule服务，那么服务间的检测就不能只用kafka做的心跳检测了，得增加一个注册中心，这样都方便调度，尤其使engine有多节点部署的需求。engine和schedule都注册在nacos中，getaway和是schedule的调度都是先从nacos中获取相应的服务地址和端口，然后再开始调取相应接口。

5、调用链的转移

原本的调用链是在配置文件中的，经过service的拆分，现在应该在schedule的配置文件中。

虽然调用链是在开发中就已经配置好的，但是我们将调用链移动到MySQL中，这样可以更好的扩展。可以通过其他途径改动MySQL中的调用链，实现实时变更。

由于调用链这种配置不会随便改动，可以通过预加载，将其加载到redis中，这样可以减小MySQL的压力。

简介

ELK是elasticsearch、logstash、kibana软件的集合，对外是作为一个日志管理系统的开源方案，它可以从任何来源、任何格式进行日志搜索、分析与可视化展示。
基本组成软件：

elasticsearch：一个开源分布式搜索引擎，提供收集、分析、存储数据三大功能。
kibana：一个基于web的图形界面，用于搜索、分析和可视化存储在elasticsearch中的日志数据。
logstash：一个服务端的数据处理管道，可以从多个源中提取数据，对其进行转换，然后将其存储到Elasticsearch中。简单来说就是日志的收集、分析、过滤工具。

搭建步骤

使用版本是7.9.3，部署前我们可以先提前从官网上下载下面4个安装包：
elasticsearch-7.9.3-linux-x86_64.tar.gz
kibana-7.9.3-linux-x86_64.tar.gz
logstash-7.9.3.tar.gz

这4个组件可以部署在不同的机器上，只要机器之间是端口开放即可
本文档中elasticsearch、logstash、kibana部署在一台机器，filebeat部署在有业务服务的机器上。

创建用户和解压文件
groupadd elk
useradd elk -g elk
解压文件：
tar -zxvf elasticsearch-7.9.3-linux-x86_64.tar.gz -C /home/elk
tar -zxvf kibana-7.9.3-linux-x86_64.tar.gz -C /home/elk
tar -zxvf logstash-7.9.3.tar.gz -C /home/elk

cd /home/elk
mv kibana-7.9.3-linux-x86_64 kibana-7.9.3

chown -R elk:elk /home/elk/elasticsearch-7.9.3
chown -R elk:elk /home/elk/kibana-7.9.3
chown -R elk:elk /home/elk/logstash-7.9.3
部署elasticsearch
1. 切换到elk用户
  su - elasticsearch
  cd /home/elk/
2. 修改elasticsearch.yml
  cd /home/elk/elasticsearch-7.9.3/config
  vi elasticsearch.yml
  在文件末尾增加以下内容
  # 集群初始主节点
  cluster.name: “es-cluster”
  network.host: 0.0.0.0
  node.name: “node-1”
  
  # discovery type
  discovery.type: single-node
  #discovery.seed_hosts: [“127.0.0.1”, “[::1]”]
  
  # 设置允许所有ip可以连接该elasticsearch
  network.host: 0.0.0.0
  
  # 开启监听的端口为9200
  http.port: 9200
  
  # 增加新的参数，为了让elasticsearch-head插件可以访问es
  http.cors.enabled: true
  http.cors.allow-origin: “*”
  
  # 启用密码
  xpack.security.enabled: true
  
  # 使用默认密码
  xpack.security.authc.accept_default_password: true
  xpack.security.transport.ssl.enabled: true
  如果需要外置存储和日志，需要修改path.data和path.logs
  path.data: /nfsc/cnas_csp_pase_hrx_id010797_vol1003_dev/elasticsearch
  path.logs: /nfsc/cnas_csp_pase_hrx_id010797_vol1003_dev/elasticsearch_logs
3. 修改Elasticsearch占用内存
  cd /home/elk/elasticsearch-7.9.3/config
  vi jvm.options
  修改JVM参数：
  -Xms16g
  -Xmx16g
4. 启动es的时候有可能会报类似的下面的错误【max virtual memory areas vm.max_map_count [65530] is too low】，所以我们可以通过下面的方法去处理：
  vi /etc/sysctl.conf
  文件末尾添加一行
  vm.max_map_count=655360
  保存之后执行下面的命令加载参数
  sysctl -p
5. 启动Elasticsearch
  切换用户，进入bin目录启动：
  cd /home/elk/elasticsearch-7.9.3/bin
  ./elasticsearch -d
6. 为内置账号添加密码
  
  interactive：给用户一一设置密码
```
# auto：自动生成密码
cd /home/elk/elasticsearch-7.9.3/bin/
./elasticsearch-setup-passwords interactive
```
7. 验证是否启动成功
  
  curl -XGET -u elastic ‘localhost:9200’
```
{
  "name" : "node-1",
  "cluster_name" : "es-cluster",
  "cluster_uuid" : "8eGk8_ohRbWl8ZcNSPsFDQ",
  "version" : {
    "number" : "7.9.3",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "c4138e51121ef06a6404866cddc601906fe5c868",
    "build_date" : "2020-10-16T10:36:16.141335Z",
    "build_snapshot" : false,
    "lucene_version" : "8.6.2",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}
```
部署kibana
1. 修改配置文件，文件位置在/home/elk/kibana-7.9.3/config目录下
  su - elasticsearch
  cd /home/elk/kibana-7.9.3/config
  vi kibana.yml
  添加es的配置，由于是都在同一台机器所以用localhost，如果是不同机器，就换成对应的ip即可
  # kibana端口
  server.port: 5601
  
  # 允许所有ip访问
  server.host: “0.0.0.0”
  
  # elasticsearch所在的ip及监听的地址
  elasticsearch.hosts: [“http://localhost:9200"]
  elasticsearch.username: “kibana_system”
  elasticsearch.password: “kibana_system”
  
  # kibana默认创建的索引
  kibana.index: “.kibana”
  
  # 字符编码
  i18n.locale: “zh-CN”
  
  # elasticsearch加密所需配置
  xpack.reporting.encryptionKey: “a_random_string”
  xpack.security.encryptionKey: “something_at_least_32_characters”
2. 启动kibana
  cd /home/elk/kibana-7.9.3/bin
  ./kibana &
3. 访问kibana
  http://IP:5601/
部署Logstash
1. 修改Logstash的YML配置文件
  cd /home/elk/logstash-7.9.3/config/
  vim logstash.yml
  修改以下内容
  # 配置自动刷新
  config.reload.automatic: true
  config.reload.interval: 20s
  
  # 配置可任意地址都可访问
  http.host: 0.0.0.0
  http.port: 9600
  
  # 配置es的访问密码
  xpack.monitoring.enabled: true
  xpack.monitoring.elasticsearch.username: logstash_system
  xpack.monitoring.elasticsearch.password: logstash_system
  xpack.monitoring.elasticsearch.hosts: [“http://localhsot:9200"]
2. 修改 pipelines配置文件
  - pipeline.id: gmp-logs
    queue.type: persisted
    path.config: “/home/elk/logstash-7.9.3/conf.d/*.config”
3. 创建日志的config文件
  touch /home/elk/logstash-7.9.3/conf.d/logstash-beats.conf
  写入文件内容
  input {
  beats {
  port => 5044
  }
  }
  
  filter {
  grok {
  match => [
  “message”, “%{TIMESTAMP_ISO8601:timestamp_string}%{SPACE}%{GREEDYDATA:line}”
  ]
  }
  date {
  match => [“timestamp_string”, “ISO8601”]
  }
  mutate {
  remove_field => [message, timestamp_string]
  }
  }
  
  output {
  elasticsearch {
  hosts => [“http://localhost:9200"]
  user => elastic
  password => “elastic”
  }
  stdout {
  codec => rubydebug
  }
  }
4. 启动Logstash(root用户)
  cd /home/elk/logstash-7.9.3/bin
  sh logstash -f ../conf.d/logstash-beats.conf &

Redis持久化

发表于 2023-07-31 分类于中间件

简述

redis有两种持久化方式：RDB（Redis DataBase）持久化和 AOF（Append Only File）。

RDB：通过创建数据的快照，在指定时间间隔内将redis某个时刻的数据状态保存到磁盘RDB文件中。

AOF：通过记录每个操作命令并将其追加到AOF文件中，恢复时通过执行这些命令来重建数据。

RDB持久化

RBD以快照的方式保存全量的数据，可通过save和bgsave两个命令来触发持久化。

1、save命令：会同步地将 Redis 的所有数据保存到磁盘上的一个 RDB 文件中。这个操作会阻塞所有客户端请求直到 RDB 文件被完全写入磁盘。

2、bgsave命令：会在后台异步地创建 Redis 的数据快照，并将快照保存到磁盘上的 RDB 文件中。这个命令会立即返回，Redis 服务器可以继续处理客户端请求。

AOF持久化

AOF以追加的方式保存增量的数据，AOF 的主要作用是解决了数据持久化的实时性，目前已经是 Redis 持久化的主流方式。

AOF 的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）。

流程如下：

1）当 AOF 持久化功能被启用时，Redis 服务器会将接收到的所有写命令（比如 SET, LPUSH, SADD 等修改数据的命令）追加到 AOF 缓冲区（buffer）的末尾。

2）为了将缓冲区中的命令持久化到磁盘中的 AOF 文件，Redis 提供了几种不同的同步策略：

always：每次写命令都会同步到 AOF 文件，这提供了最高的数据安全性，但可能因为磁盘 I/O 的延迟而影响性能。
everysec（默认）：每秒同步一次，这是一种折衷方案，提供了较好的性能和数据安全性。
no：不主动进行同步，交由操作系统决定何时将缓冲区数据写入磁盘，这种方式性能最好，但在系统崩溃时可能会丢失最近一秒的数据。

3）随着操作的不断执行，AOF 文件会不断增长，为了减小 AOF 文件大小，Redis 可以重写 AOF 文件：

重写过程不会解析原始的 AOF 文件，而是将当前内存中的数据库状态转换为一系列写命令，然后保存到一个新的 AOF 文件中。
AOF 重写操作由 BGREWRITEAOF 命令触发，它会创建一个子进程来执行重写操作，因此不会阻塞主进程。
重写过程中，新的写命令会继续追加到旧的 AOF 文件中，同时也会被记录到一个缓冲区中。一旦重写完成，Redis 会将这个缓冲区中的命令追加到新的 AOF 文件中，然后切换到新的 AOF 文件上，以确保数据的完整性。

4）当 Redis 服务器启动时，如果配置为使用 AOF 持久化方式，它会读取 AOF 文件中的所有命令并重新执行它们，以恢复数据库的状态。

两者优缺点

RDB-优点

集中备份，则文件紧凑， dump.rdb，非常适合备份、全量复制的场景。
容灾性好，RDB 文件可以直接拷贝使用，用于容灾恢复。
恢复速度快，RDB文件集中紧凑，则速度快

RDB-缺点

实时性低，RDB 是间隔一段时间进行持久化，无法实时持久化。如果在这时间段发生故障，则数据会丢失。
存在兼容问题，Redis 演进过程存在多个格式的 RDB 版本，存在老版本 Redis 无法兼容新版本 RDB 的问题。

AOF-优点

实时性好，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次命令操作就记录到 aof 文件中一次。
通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。

AOF-缺点

AOF 文件比 RDB 文件大，且 恢复速度慢。
数据集大 的时候，比 RDB 启动效率低。

两者如何选择

1、只选RDB，可能会有数分钟的数据丢失。

2、只选AOF，不利于备份，恢复速度也慢。

3、两者配合，两种持久化方式都选，这种情况下Redis重启时会优先载入AOF文件来恢复数据，因为AOF文件的数据集比RDB全。

4、都不选，不持久化。

故障数据恢复

Redis 启动时加载数据的流程：

1、判断AOF开启且AOF文件是否存在，存在则优先加载

2、如果AOF关闭或者不存在，则加载RDB文件

3、文件加载成功后则Redis启动成功

4、加载失败，则启动失败

导图

阅读全文 »

REST

RESTful本身是一种风格而不是规范，本文为该风格的规范实现的最佳实践，本文档详细说明了HTTP RESTful API的定义和使用规范，作为接口调用者和实现者的重要参考。

接口风格

遵循RESTful设计风格，同时控制复杂度及易于使用，仅遵循大部分原则。遵循原则：

使用https协议
版本号放入URL或Header
只提供json返回格式
post,put上使用json作为输入
使用http状态码作为错误提示
Path（路径）尽量使用名词，不使用动词，把每个URL看成一个资源
使用HTTP动词（GET,POST,PUT,DELETE）作为action操作URL资源
过滤信息
- limit：指定返回记录数量
- offset：记录开始位置
- direction：请求数据的方向，取值prev-上一页数据；next-下一页数据
- page：第几页
- per_page：每页条数
- total_count：总记录数
- total_pages：总页数，等于page时，表示当前是最后一页
- sort：column1,column2排序字段
- orderby：排序规则，desc或asc
- q：搜索关键字（uri encode之后的）
返回结果
- GET：返回资源对象
- POST：返回新生成的资源对象
- PUT：返回完整的资源对象
- DELETE：返回一个空文档
速率限制
- X-RateLimit-Limit: 每个IP每个时间窗口最大请求数
- X-RateLimit-Remaining: 当前时间窗口剩余请求数
- X-RateLimit-Reset: 下次更新时间窗口的时间（UNIX时间戳），达到下个时间窗口时，Remaining恢复为Limit

未遵循原则：

Hypermedia API（HATEOAS），通过接口URL获取接口地址及帮助文档地址信息
限制返回值的域，fields=id,subject,customer_name
缓存，使用ETag和Last-Modified

参考：

模块和版本说明

接口模块相互对立且有版本管理，模块名作为APP配置项进行存储，每个模块的版本号version和endpoint在应用初始化时调用api模块信息接口（通过传递客户端应用名称和版本号获取各个API模块的endpoint和version）获取并存储。

示例模块及最新版本号：

模块模块用途最新版本号account帐户v1sms短信v1open一些开放接口，不需要公共参数v1

公共参数

Headers

公共请求参数是指每个接口都可能需要传递的参数，公共参数通过header传递。

参数是否必须说明及header格式app所有接口必须请求客户端应用标识，取值*-ios、*-android、*-pc、*-h5
header格式：
X-Co-App: $appuser_idApp登录后所有接口都传，
Web通过session机制获取用户标识
header格式：
Authorization: CoAPI base64(user_id:token)tokenApp登录后所有接口都传，
Web通过session机制获取授权访问令牌
header格式：
Authorization: CoAPI base64(user_id:token)

Web应用通过cookies传递session id，user_id和token无需传递，接口会从session自动获取；
同一token值在App和Web各应用间通用（token即为session id）；
APP修改user-agent，在原有user-agent的尾部添加$app/$version和NetType/$value。如：
- Dalvik/2.1.0 (Linux; U; Android 6.0.1; MI 4LTE MIUI/V7.5.3.0.MXGCNDE) $app-android/3.0.0 NetType/4G
- Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_2 like Mac OS X) AppleWebKit/603.2.4 (KHTML, like Gecko) $app-ios/3.0.0 NetType/WIFI
app取值及释义示例

app取值客户端名称【域名】admin-pc管理中心PC网页版【admin.url.com】admin-h5管理中心手机网页版【admin.url.com】admin-ios管理中心iOS版admin-android管理中心Android版

Cookies

用于告知服务端是否支持Webp的Cookie：cookie name是supportWebp，取值是1（支持）和0（不支持），未传递时服务端默认取值为0。
Webview植入Session的Cookie：

JWT & OAuth2

Json Web Token可用于替代session-cookie机制。但会存在一些问题，比如为过期token强制失效问题（用户修改了密码后，无法强制其他的终端token全部失效）。
OAuth2是授权其他开发者访问自己应用有限权限的授权机制。

权限

权限分为
- none：无需任何授权；
- token：需要用户登录授权，可通过header Authorization和Cookie CoSID传递；
- admintoken：需要管理员登录授权，可通过header Authorization和Cookie CoCPSID传递；
- token || admintoken：用户登录授权或管理员登录授权都可以；
- sign：需要签名，一般用于服务端内部相互调用。

状态码说明

正确
接口正常访问情况下，服务器返回2××的HTTP状态码。

HTTP状态码200 OK - 表示已在响应中发出、资源更改成功（GET、PUT）201 Created - 新资源被创建（POST）204 No Content - 资源被删除（DELETE）

错误
当用户访问接口出错时，服务器会返回给一个合适的4××或者5××的HTTP状态码；以及一个application/json格式的消息体，消息体中包含错误码code和错误说明message。

5××错误(500=<status code)为服务器或程序出错，客户端只需要提示“服务异常，请稍后重试”即可，该类错误不在每个接口中列出。
4××错误(400=<status code<500)为客户端的请求错误，需要根据具体的code做相应的提示和逻辑处理，message仅供开发时参考，不建议作为用户提示。
部分错误示例：

codemessageHTTP状态码InvalidToken未登录或授权过期，请登录401 UnauthorizedValidationError输入字段验证出错，缺少字段或字段格式有误422 Unprocessable EntityAccountNotExist账户名不存在404 Not FoundInvalidPassword密码错误401 UnauthorizedNotFound请求的资源不存在404 Not FoundAccountHasExist账户名已经存在409 ConflictMobileHasBinded手机号已经绑定其他账户409 ConflictInvalidSign参数签名验证未通过403 ForbiddenInvalidSMSCode短信验证码错误403 ForbiddenExpiredSMSCode过期的短信验证码403 ForbiddenFrequencyLimit发送过于频繁，请稍后再试403 ForbiddenTimesExceeded达到最大发送次数限制，请明天再试403 ForbiddenVerifyTimesExceeded达到最大校验次数，请明天再试403 ForbiddenRateLimitExceeded接口调用次数超过限制，请稍后再试429 Too Many Requests InternalError服务异常，请稍后再试500 Internal Server Error

HTTP状态码参考

参数传递

遵循RESTful规范，使用了GET, POST, PUT, DELETE共4种请求方法。

GET：请求资源，返回资源对象
POST：新建资源，返回新生成的资源对象
PUT：新建/更新资源，返回完整的资源对象
DELETE：删除资源，返回body为空

GET请求不允许有body，所有参数通过拼接在URL之后传递，所有的请求参数都要进行遵循RFC 3986的URL Encode。
DELETE删除单个资源时，资源标识通过path传递，批量删除时，通过在body中传递JSON。
POST, PUT请求，所有参数通过JSON传递，可选的请求参数，只传有值的，无值的不要传递，contentType为application/json。

4种请求动作中，GET、PUT、DELETE是幂等的；只有POST是非幂等的。幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。 是非幂等是判断接口使用POST还是PUT的决定条件

注意： APP端获取json数据时，对于数值类型字段必须以数值类型转换，无论传递过来的值是否带引号。

速率限制Rate Limiting

为了防止API被恶意调用，对API调用进行速率限制。
速率限制为每IP每15分钟5000次（dev/qa为10W）调用（15分钟是一个时间窗口）。
限制是针对所有接口模块一起计算的（Redis key为APIRL:{IP}），暂时没有特殊的模块或单个接口（未来可能有）。
你可以通过每个接口返回的HTTP headers了解当前速率限制的情况:
- X-RateLimit-Limit: 每个IP每个时间窗口最大请求数
- X-RateLimit-Remaining: 当前时间窗口剩余请求数
- X-RateLimit-Reset: 下次更新时间窗口的时间（UNIX时间戳），达到下个时间窗口时，Remaining恢复为Limit
超出速率限制，返回以下错误

安全注意事项

用户登录后用户的token；aliyun OSS的bucket、AccessKey ID与AccessKey secret；微视频的appid、sign、bucket；这些关键数据通过调用接口获得，需要在客户端以安全的方式存储。
音频视频在APP内的存储，不允许被拷贝（即使越狱或root后拿走也无法使用）。

测试工具

推荐Chrome浏览器插件Postman作为接口测试工具， Postman下载地址

文档生成工具

生成的工具为apidoc，详细阅读官方文档：http://apidocjs.com

调用示例

伪代码
PHP

API模块信息获取

App配置文件中仅存储api模块名，App初始化时请求获取api模块信息，获取各个api模块的信息（endpoint和version）。

Git仓库的子目录独立成新仓库

发表于 2023-06-13

需求描述

我有一个仓库AAA，目录结构如下：

$ tree
├── .git
├── common-api     
├── commons-pojo
├── commons-utils  
├── account 
└── payment 
└── product

现在我需要把common-api、commons-pojo、commons-utils独立为一个新仓库xxx-common
从网上找到可以用”git filter-branch”和”git subtree split”两种方式独立目录为仓库，但是”git subtree split”只能独立一个目录为仓库，如果需要独立多个目录为仓库需要使用”git filter-branch”。

阅读全文 »

DDD分层架构规范

发表于 2023-05-25 分类于 JAVA

分层架构图

DDD

简述

Controller层：接口层，负责对前端展示的路由和适配；如果需要的话，消费事件和发送消息通知等也可以放在这里；
Application层：主要负责获取输入，组装上下文，参数校验，调用领域层做业务处理
Domain层：领域是应用的核心，主要是封装了核心业务逻辑，通过领域服务（Domain Service）、领域对象（Entity）的方法对App层提供业务实体和业务逻辑计算；
Infrastructure层：主要负责技术细节问题的处理，比如数据库的CRUD、搜索引擎、文件系统、分布式服务的RPC等；

分层说明

APP层采用CQE模型，查询和命令分离
AppService调用实体和IRepo进行编排实现简单业务，通过调用DomainService实现复杂业务场景
AppService和DomainService均为无状态服务
App只允许调用仓储以及实体自带方法，不允许写任何方法，避免出现AppService过大的情况
DomainService封装所有跨实体的业务逻辑
为避免出现AppService之间或者Domainservice之间相互调用，抽取出两者公共部分为一个Helper

聚合根和实体

按聚合根分包，和包名一样的实体为聚合根
可以识别的聚合根就写成聚合根，否则做成实体
聚合根的一致性由自己保障
跨实体的操作放到领域服务中

领域对象实体为充血模型，为一般业务对象，具备业务属性和业务行为

实体都有自己的唯一标识通常
实体可以不和表一一对应，通常操作单个表，可以操作多表

领域服务

某个操作过程或转换过程不是实体的职责时，我们便应该将该操作放在一个单独的接口中，即领域服务。

用于实现某个领域的任务，不适合放在实体对象上时，就放在领域服务上
放在实体的静态方法上有悖DDD
避免在实体中调用资源库，数据通过AppService调用Repo传入
如果有复杂逻辑，其中间的状态依赖前面步骤结果查询数据库作为后续逻辑的输入，通过把Repo传入到Domainservice的方式达到无状态效果

传输对象

DTO：接受Controller层发来的请求，返回结果
Entity ：将DTO转换为要操作的领域层对象

无状态

一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务本身不存储任何信息
有状态服务（stateful service）则相反，它会在自身保存一些数据，先后的请求是有关联的
无状态服务的优势在于可以很方便地水平伸缩

MySQL线上索引创建

发表于 2023-04-10 分类于 MySQL

简述

如果在线上环境，需要新建一个索引，会发生什么，会不会导致不可用，具体的创建步骤又是啥。

首先肯定会有一段时间导致表不可用的，主要就是看不可用的时间长短。

在不同的版本上主要有三种创建方式：Copy Table方式、Inplace方式、Online方式

Copy Table方式

早期版本，直接通过复制表实现

步骤

1、先为原表table创建临时表table_copy。

2、向临时表table_copy添加索引。

3、将原表table数据查询后插入到临时表table_copy，在将原表table改名为table_1。

4、在将临时表table_copy改名为table

不可用

在创建的过程中原表是可读的，但是在查询插入阶段是不可写的。

Inplace方式

MySQL5.5版本，没有复制临时表，减少了空间消耗，相对copy方式是一种进步。

步骤

1、读取主表索引列数据，并对数据排序

2、直接新建索引

不可用

创建过程中原表可读不可写。

Online方式

MySQL5.6.7版本，在原本inplace的基础上增添了可写的功能，相对inplace又是一种进步。

步骤

1、使用inplace方式创建索引，不用临时表。

2、在遍历聚簇索引，收集记录插入到新索引的过程中，记录修改保存到row log

3、聚簇索引遍历结束，并将所有记录插入之后，重放row log，是的记录一致。

不可用

只有在步骤3，重放row log的过程中锁表不可写。

JVM加载过程

发表于 2023-04-09 分类于 JAVA

什么是JVM类加载

指将编译后的class文件，读到内存中，首先将其放在运行时数据区的方法区内，然后再堆内创建class对象。class对象封装了类在方法区内的数据结构，并提供了访问方法区内的数据结构的接口。

类加载器

自带加载器

自带加载器有三个：

1、启动类加载器：负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。

2、扩展类加载器：该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载DK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。

3、应用程序类加载器：该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

类加载的三种方式

命令行启动应用时候由JVM初始化加载
通过Class.forName()方法动态加载
通过ClassLoader.loadClass()方法动态加载

双亲委派机制

1、一个类加载器收到类加载请求，不会首先自己去加载这个类，而是把请求委托到父类加载器去完成。

2、依次向上。

3、所有类加载请求都会被传递到顶层的启动类加载器中。

4、只有父加载器无法加载该类，才会由子类尝试加载。

类的生命周期

生命周期主要包括7个部分：加载，验证，准备、解析、初始化、使用、卸载

类加载过程：加载，验证，准备、解析、初始化

其中 验证，准备、解析 这三个部分统称为连接

加载，验证，准备、初始化这四个部分是按顺序发生的，而解析则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。其他阶段是按顺序发生，不一定按顺序结束，通常是相互交叉的混合进行，在一个阶段执行的过程中调用另一个阶段。

加载：查找并加载类的二进制数据

验证：确保被加载类的正确性

准备：为类的静态变量分配内存，并将其初始化默认值

解析：把类中的符号引用转换为直接引用

初始化：到此才开始真正执行Java程序代码，执行类构造器方法的过程

简述

发送过程中丢失

发送方式

acks参数设置

小结

同步过程中丢失

拉取过程中丢失

需求描述

1、没有架构的架构

2、抽取engine服务

3、拆分service

4、新增注册中心

5、调用链的转移

简介

搭建步骤

interactive：给用户一一设置密码

curl -XGET -u elastic ‘localhost:9200’

简述

RDB持久化

AOF持久化

两者优缺点

两者如何选择

故障数据恢复

导图

REST

接口风格

模块和版本说明

公共参数

Headers

Cookies

JWT & OAuth2

权限

状态码说明

参数传递

速率限制Rate Limiting

安全注意事项

测试工具

文档生成工具

调用示例

API模块信息获取

需求描述

分层架构图

简述

分层说明

聚合根和实体

领域服务

传输对象

无状态

简述

Copy Table方式

步骤

不可用

Inplace方式

步骤

不可用

Online方式

步骤

不可用

什么是JVM类加载

类加载器

自带加载器

双亲委派机制

类的生命周期