## java学习记录
**author: xiak**
**last update: 2021-12-20 10:11:11**
----
[TOC=3,8]
----
### 集群
#### 什么是集群
集群通常是由**一个地域的数据中心的N台机器组成**的一组**统一对外提供服务**的服务器群,每台服务器就是最普通的单点服务器(单点应用),每台机器的外网IP不同,既可以单独提供服务,又能作为一个整体提供服务,集群内通过协调机制保持同步。通常一个数据中心的机器都在内网中,所以**一个集群内的机器间通信可以走内网**。(如果一个地域数据中心创建多个集群,多个集群间的通信也可以走内网。只要在同一个数据中心内都可以走内网。)
----
#### 为什么要集群
受物理硬件等客观限制,单台服务器的承载能力总会有极限,无论是内存还是磁盘,或是来自软件方面的限制(linux 每个进程可打开的资源等限制),并且单台服务器容易出现单点故障。所以大的应用最终都会走向集群模式。
----
#### 地域集群
通常一个数据中心一个集群,如 腾讯云-深圳1区集群,阿里云-北京A区集群等等。对外服务时都是同一个域名和端口,通过 DNS **负载均衡** 和 **就近分配**,如 河北的用户访问就被分配到北京阿里云的集群了,四川的用户访问就被分配到 深圳腾讯云的集群了。
集群也可以跨地域机房,比如 北京和深圳的共同组成一个集群,但是通常不会这样做,因为这样不能利用同一集群内**内网访问速度的优势**,完全没必要跨机房组集群。可以一个地域一个集群,然后集群间跨地域数据同步即可。
----
#### 集群DNS
集群内的机器不直接对外暴露IP,而是由集群整体暴露一个统一的域名,用户并不关心当前访问是由集群内哪台机器提供服务的,以及集群有多少台机器,根据负载情况动态增减调整集群内的机器数量,这对上层用户来说是透明不可见的。当服务无状态时,整个应用就是分布式架构的了。
----
#### 集群灾备
通常一份数据会保留三份,两份作为备份,以便在出现故障时恢复数据,最大程度上保证系统可用。**灾备副本必须在不同的数据中心,即不同的集群。** 因为数据与灾备在同一个数据中心、同一个机房 就没意义作为备份的意义了,数据中心或者机房失火,全部都烧了,哪怕数据在不同机器上也没用,都烧光了,所以灾备在不同的数据中心才有意义。(负载均衡节点充当了反向代理角色,起转发流量作用)
[容错,高可用和灾备 - 阮一峰的网络日志](https://www.ruanyifeng.com/blog/2019/11/fault-tolerance.html)
上面三个方面可以结合起来,设计一个可靠的系统。
- 容错:发生故障时,如何让系统继续运行。
- 高可用:系统中断时,如何尽快恢复。
- 灾备:系统毁灭时,如何抢救数据。
[什么是 Docker | Docker 从入门到实践](https://vuepress.mirror.docker-practice.com/introduction/what/)
[OS-level virtualization - Wikipedia](https://en.wikipedia.org/wiki/OS-level_virtualization)
> 容器中虚拟了操作系统,而虚拟机则是虚拟了硬件系统。注意是操作系统级别的虚拟化,而不是应用软件层的虚拟化。相当于系统上又起了很多轻量级系统(容器),要知道这些容器的操作系统本质上其实也是进程,底层与硬件交互的宿主操作系统还是一个,所以开销比虚拟机低很多。
----
#### 应用节点部署
单点应用通常是一台服务器上部署了应用,也启动了mysql redis 等服务,所以可以看作是 一台服务器上 部署了 一个应用节点,一个 mysql 节点,一个 redis 节点。
集群模式下通常不会让一台机器部署多种节点,而是根据服务器配置不同,有针对性的专门部署节点,如 一个 由10台服务器组成的集群,可能会用5台性能比较好的拿出来专门部署应用,3台磁盘IO比较强的专门部署 mysql,2台内存比较大的专门部署 redis ,这样就是 5个应用节点,3个mysql节点,2个redis节点。
更进一步,甚至一整个数据中心的集群全部用来专门部署一种节点,如 mysql 集群,redis 集群。
----
#### 云服务器
在 地域下面,创建一个实例,就是一台云服务器 CVM (Cloud Virtual Machine)。
地域 下 还有 可用区(随机可用区、上海二区、上海三区、上海四区、上海五区)
所以 云服务器实例的地域:上海四区
IP地址默认有一个 公网IP、一个内网IP,域名解析解析到 公网IP上就可以做WEB节点了。那如果有多台实例 用一个域名 怎么动态解析呢,怎么实现就近访问,负载均衡呢?
> 可用区:**每个可用区都是独立的数据中心**,可用区之间电力和网络设备互相独立,网络互通,适合部署同城多活的高可用业务, **同一可用区内的主机网络延时更小**。(北京3区-B、上海1区-A、广东2区-A)
~~~
区域及可用区
区域
根据数据中心地理位置划分,不同区域间内网隔离,不能互相访问。
可用区
一个区域包括多个可用区,每个可用区都相互独立但网络互通,同一可用区内的主机网络延时更小。如果业务需要同城多活,建议您部署在不同可用区。详情请参考:区域与可用区文档 https://docsv3em.qingcloud.com/operation/resource/manual/region/area_resource/。
常见问题
1.如何选择区域?
建议靠近您的业务区域选择区域,可以减少网络时延,提高访问速度。另外,不同区域的资源价格可能有差异,您可以根据价格选择合适的区域。
2.如何选择可用区?
每个可用区都相互独立,规格相同。如果您初次创建资源,您可选择系统分配。如果您的业务需要同城多活,建议您将主机部署在不同可用区,通过同一个负载均衡器对外提供服务。如果您的云服务器之间需要较低的网络时延,则建议您将它们部署在相同的可用区内。
3.不同区域或不同可用区的云服务器是否可以通过内网相互访问?
不同区域的云服务器内网互不相通,如果有访问需求,您可以通过绑定公网IP通过公网相互访问或通过隧道服务访问。同区域内不同可用区的云服务器如果处在同一个多可用区部署的私有网络下,可以内网互通。
~~~
----
#### 负载均衡
[实例管理 - 负载均衡 - 控制台](https://console.cloud.tencent.com/clb/instance?rid=4)
[负载均衡 产品概述 - 产品简介 - 文档中心 - 腾讯云](https://cloud.tencent.com/document/product/214/524)
> 为提供更加弹性、稳定、高质量的服务,从2021年11月2日00:00:00起,所有负载均衡实例将进行架构升级,升级后提供并发连接数5万,每秒新建连接数5000,每秒查询数(QPS)5000 的性能保障。全新架构的负载均衡内网、外网实例价格将定为0.2元/小时(部分地域为0.3元/小时)
~~~
负载均衡(Load Balancer,简称LB)提供安全快捷的流量分发服务,来自多个公网地址的访问流量经由 LB 可以自动分配到多台云服务器上,并支持自动检测并隔离故障云服务器,提供业务系统的服务能力和可用性。负载均衡支持千万级别并发访问请求,可轻松应对大流量访问,满足业务需求。
[负载均衡 | QingCloud 文档](https://docsv3.qingcloud.com/network/loadbalancer/)
~~~
----
#### 弹性网卡
[弹性网卡 - 文档中心 - 腾讯云](https://cloud.tencent.com/document/product/576)
----
#### DNS 服务器(域名解析、DNS 解析)
[1.1.1.1 — The free app that makes your Internet faster.](https://1.1.1.1/)
[Cloudflare推出最快公共DNS服务1.1.1.1,速度远超8.8.8.8](https://mp.weixin.qq.com/s/rZwwi2iG9ULXNuFOUbZtvQ?)
[系统状态 - DNSPod 服务与支持](https://support.dnspod.cn/status/)
[DNS.TECH 网站域名解析免费检测工具 - 网络拨测_故障诊断_网站备案 - 腾讯云 DNSPod](https://dns.tech/baidu.com)
~~~
DNS 服务商
ns2.baidu.com
ns3.baidu.com
ns4.baidu.com
ns1.baidu.com
ns7.baidu.com
~~~
~~~
DNS 服务商
已使用腾讯云 DNSPod 域名解析服务收起
f1g1ns1.dnspod.net
f1g1ns2.dnspod.net
(北京市 162.14.25.230 162.14.24.230 解析时间 平均在 32ms 左右)
(免费版 负载均衡2 条)
DNS 服务商解析结果
解析记录正常收起
A 212.64.100.122
NS f1g1ns2.dnspod.net.
NS f1g1ns1.dnspod.net.
SOA freednsadmin.dnspod.com. 1550299945 3600 180 1209600 180
Dig 详情
Public DNS 解析结果
解析记录正常收起
A xxx.xxx.xxx.xxx
NS f1g1ns2.dnspod.net.
NS f1g1ns1.dnspod.net.
SOA freednsadmin.dnspod.com. 1550299945 3600 180 1209600 180
~~~
> 域名解析(DNS 解析) 一个域名只能解析到 一个IP,因为 A记录主机名不能重复解析。可以?还真可以?那这样到底请求那个IP啊,自带负载均衡?在创建第三个 相同的 A记录使提示 “子域名负载均衡数量超出限制”,看来确实有负载均衡的功效啊,不过免费的默认最大只能两个。
[负载均衡之DNS域名解析,实现一个域名对应多个IP地址_adsadadaddadasda的博客-CSDN博客_一个dns对应多个ip](https://blog.csdn.net/adsadadaddadasda/article/details/82902618)
> 次*域名解析*请求都会根据对应的负载均衡算法计算出一个不同的IP地址并返回,这样*A*记录中配置多个服务器就可以构成一个集群,并可以实现负载均衡。
> 事实上,大型网站总是部分使用DNS域名解析,利用域名解析作为第一级负载均衡手段,即域名解析得到的一组服务器并不是实际提供服务的物理服务器,而是同样提供负载均衡服务器的内部服务器,这组内部负载均衡服务器再进行负载均衡,请请求发到真实的服务器上,最终完成请求。
[网站测速|网站速度测试|网速测试|电信|联通|网通|全国|监控|CDN|PING|DNS 17CE.COM](http://17ce.com/site)
[Query: www.baidu.com - Google Public DNS](https://dns.google/query?name=www.baidu.com)
~~~
{
"Status": 0 /* NOERROR */,
"TC": false,
"RD": true,
"RA": true,
"AD": false,
"CD": false,
"Question": [
{
"name": "www.baidu.com.",
"type": 1 /* A */
}
],
"Answer": [
{
"name": "www.baidu.com.",
"type": 5 /* CNAME */,
"TTL": 1059,
"data": "www.a.shifen.com."
},
{
"name": "www.a.shifen.com.",
"type": 5 /* CNAME */,
"TTL": 184,
"data": "www.wshifen.com."
},
{
"name": "www.wshifen.com.",
"type": 1 /* A */,
"TTL": 232,
"data": "103.235.46.39"
}
]
}
~~~
[DNS 原理入门 - 阮一峰的网络日志](http://www.ruanyifeng.com/blog/2016/06/dns.html)
----
#### CDN 内容分发网络
[内容分发网络 CDN - 文档中心 - 腾讯云](https://cloud.tencent.com/document/product/228)
----
#### 在云上部署集群
以腾讯云为例,我们在腾讯云上使用 pulsar :
1. 进入 消息队列 TDMQ - 控制台,首先 地域已默认 上海(云上的所有资源,都是在某个地域下)
2. 点击创建按钮,创建一个集群:
~~~
集群类型:虚拟集群(默认,只有这一个选项)
使用虚拟化的计算和存储资源,根据用量自动分配,使用有一定限制,无需为资源付费
单个主账号最多创建5个虚拟集群
集群类型:
虚拟集群: 使用虚拟化的计算和存储资源,根据用量自动分配,使用有一定限制,无需为资源付费,每个用户最多可以创建5个虚拟集群。
专享集群: 独占物理资源,数据安全,使用几乎无限制,未达到使用要求会额外计算资源占用费。
~~~
3. 操作两次,我们就在 上海下 创建了两个集群,注意创建集群时并没有指定集群内要多少台机器,因为是虚拟化的,自动分配的。
~~~
上海 华东地区
j1
http://pulsar-jebg245o53m2.tdmq-pulsar.ap-sh.qcloud.tencenttdmq.com:5039
http://pulsar-jebg245o53m2.tdmq-pulsar.ap-sh.public.tencenttdmq.com:8080
j2
http://pulsar-jze7or9kdow7.tdmq-pulsar.ap-sh.qcloud.tencenttdmq.com:5039
http://pulsar-jze7or9kdow7.tdmq-pulsar.ap-sh.public.tencenttdmq.com:8080
广州 华南地区
j1 http://pulsar-24k5nwqd8ko5.tdmq.ap-gz.qcloud.tencenttdmq.com:5035
新加坡 亚太东南
j1 http://pulsar-9nprpeo9jga7.tdmq.ap-sg.qcloud.tencenttdmq.com:5000
~~~
这样我们有了 三个地区 的总共4个集群。
从 **VPC 内网接入地址** 我们可以看到 集群 id 不同,`ap-sh` `ap-gz` `ap-sg` 地域也不同,还有不同地域端口也不同,其它基本都是相同的。(VPC 内网接入地址 和 公网接入地址 基本也是一样的)
在同一个地域的多个集群可看作是**同城多活**。不同地域的多个集群可看作是**异地多活**。
默认只开放了内网,那台上海地域的云服务器实例 可以用 VPC 内网接入地址 访问上海的 pulsar 集群。
topic: `pulsar-jebg245o53m2/name/topic` 集群id / 命名空间 / topic,可以看到 **pulsar 的 租户 就是腾讯云这里的 集群**了,**租户/集群 间是相互完全隔离和独立的,租户/集群间没有任何关系**。**消息是属于某个集群下的一个 命名空间下的**,配置权限也是在命名空间上。
pulsar 租户可以跨集群分布,腾讯云不支持这一点。[多租户 · Apache Pulsar](https://pulsar.apache.org/docs/zh-CN/next/concepts-multi-tenancy/)
[消息队列 Pulsar 版 集群管理 - 操作指南 - 文档中心 - 腾讯云](https://cloud.tencent.com/document/product/1179/52145) 或者说 腾讯云 去掉了租户这一层的概念。因为对 腾讯云来说,我们是他的客户,也是他pulsar平台的一个租户。
> 集群是 TDMQ Pulsar 版中的一个资源维度,不同集群的命名空间、Topic、角色权限等完全隔离。每个集群会有集群的资源限制例如 Topic 总数、消息保留时长等。常见的使用方式如:开发测试环境使用一个专门集群,生产环境使用一个专门的集群。
----
### pulsar
#### 客户端设置步骤
在应用程序创建生产者/消费者之前,Pulsar 客户端库需要启动一个设置阶段,包括两个步骤:
1. **客户端将尝试通过向服务器(Broker)发送 HTTP 查找请求**,来确定主题(Topic)所在的服务器(Broker)。 客户端通过查询 ZooKeeper 中 (缓存) 的元数据,来确定这条消息的 topic 在哪个 broker 上,如果该 topic 不在任何一个 broker 上,则把这个 topic 分配在负载最少的 broker 上。
2. 当客户端获取了broker的地址之后,**将会创建一个TCP连接** (或复用连接池中的连接) 并且进行鉴权。 客户端和broker通过该连接交换基于自定义协议的二进制命令。 同时,客户端会向broker发送一条命令用以在broker上创建生产者/消费者,该命令将会在验证授权策略后生效。
每当 TCP 连接中断时, 客户端将立即重新启动上述步骤的设置阶段, 并将继续尝试使用指数退避重新建立生产者或消费者, 直到上述步骤执行成功为止。
这个过程可以以描述为:
1. 不论是创建 生产者/消费者,都 携带参数 topic ,http 请求任意一台 Broker http 服务器以获取 topic 所在的 broker 服务器 地址。
2. tcp 连接这个 broker 服务器 地址,向其发送创建 生产者/消费者 的命令。
Broker 是无状态的,所以第一步 http 请求任意一台 Broker 服务器都可以(**这就是分布式系统的特点,节点是无状态的,客户端请求任意节点都可以,任意节点都能提供相同的服务**),不过客户端肯定最好不要使用具体的 host ip 地址,而应该 使用 域名 DNS 的方式,这样避免了单点问题,而且用IP硬编码不灵活,并且 有 DNS 还能起到负载均衡的效果。
不过这样每次 创建 生产者/消费者 都需要请求两次,第一次 http 请求 **查询 topic 所在 Broker 服务器**,如果能去掉这一步就好了。但不能,因为必须要路由到有 topic 的 Broker 才行,系统是分布式的,客户端不知道资源应该由哪个节点处理,所以这一步是少不了的。除非客户端直接与一个代理进行交互,不用关心资源所在的 Broker。
只能说现阶段这样不好,增加了客户端的复杂度,应该使路由资源这一步对客户端不可见透明才好。
> 无法做到只提供一个节点给客户端,让这一路由过程对客户端不可见,因为这恰好是分布式系统的特点,这样才能提高吞吐,否则单点代理也会成为吞吐的瓶颈。所以分布式系统无法让客户端保持轻量,传统 redis mysql 太轻量了,一个简单的 tcp 客户端就行了,所以也只能做简单的事。
> apache-pulsar-2.9.1-src.tar.gz 用 360解压 会有问题,缺少文件或者路径被截断了,可能是目录层级太多了,文件名不能过长了,所以使用 tar 命令解压,不要使用 360解压。
[裸机多集群部署 · Apache Pulsar](https://pulsar.apache.org/docs/zh-CN/next/deploy-bare-metal-multi-cluster/)
[zookeeper 集群搭建 - YSOcean - 博客园](https://www.cnblogs.com/ysocean/p/9860529.html)
> zookeeper 节点数量必须是奇数
- 开始
- 公益
- 更好的使用看云
- 推荐书单
- 优秀资源整理
- 技术文章写作规范
- SublimeText - 编码利器
- PSR-0/PSR-4命名标准
- php的多进程实验分析
- 高级PHP
- 进程
- 信号
- 事件
- IO模型
- 同步、异步
- socket
- Swoole
- PHP扩展
- Composer
- easyswoole
- php多线程
- 守护程序
- 文件锁
- s-socket
- aphp
- 队列&并发
- 队列
- 讲个故事
- 如何最大效率的问题
- 访问式的web服务(一)
- 访问式的web服务(二)
- 请求
- 浏览器访问阻塞问题
- Swoole
- 你必须理解的计算机核心概念 - 码农翻身
- CPU阿甘 - 码农翻身
- 异步通知,那我要怎么通知你啊?
- 实时操作系统
- 深入实时 Linux
- Redis 实现队列
- redis与队列
- 定时-时钟-阻塞
- 计算机的生命
- 多进程/多线程
- 进程通信
- 拜占庭将军问题深入探讨
- JAVA CAS原理深度分析
- 队列的思考
- 走进并发的世界
- 锁
- 事务笔记
- 并发问题带来的后果
- 为什么说乐观锁是安全的
- 内存锁与内存事务 - 刘小兵2014
- 加锁还是不加锁,这是一个问题 - 码农翻身
- 编程世界的那把锁 - 码农翻身
- 如何保证万无一失
- 传统事务与柔性事务
- 大白话搞懂什么是同步/异步/阻塞/非阻塞
- redis实现锁
- 浅谈mysql事务
- PHP异常
- php错误
- 文件加载
- 路由与伪静态
- URL模式之分析
- 字符串处理
- 正则表达式
- 数组合并与+
- 文件上传
- 常用验证与过滤
- 记录
- 趣图
- foreach需要注意的问题
- Discuz!笔记
- 程序设计思维
- 抽象与具体
- 配置
- 关于如何学习的思考
- 编程思维
- 谈编程
- 如何安全的修改对象
- 临时
- 临时笔记
- 透过问题看本质
- 程序后门
- 边界检查
- session
- 安全
- 王垠
- 第三方数据接口
- 验证码问题
- 还是少不了虚拟机
- 程序员如何谈恋爱
- 程序员为什么要一直改BUG,为什么不能一次性把代码写好?
- 碎碎念
- 算法
- 实用代码
- 相对私密与绝对私密
- 学习目标
- 随记
- 编程小知识
- foo
- 落盘
- URL编码的思考
- 字符编码
- Elasticsearch
- TCP-IP协议
- 碎碎念2
- Grafana
- EFK、ELK
- RPC
- 依赖注入
- 开发笔记
- 经纬度格式转换
- php时区问题
- 解决本地开发时调用远程AIP跨域问题
- 后期静态绑定
- 谈tp的跳转提示页面
- 无限分类问题
- 生成微缩图
- MVC名词
- MVC架构
- 也许模块不是唯一的答案
- 哈希算法
- 开发后台
- 软件设计架构
- mysql表字段设计
- 上传表如何设计
- 二开心得
- awesomes-tables
- 安全的代码部署
- 微信开发笔记
- 账户授权相关
- 小程序获取是否关注其公众号
- 支付相关
- 提交订单
- 微信支付笔记
- 支付接口笔记
- 支付中心开发
- 下单与支付
- 支付流程设计
- 订单与支付设计
- 敏感操作验证
- 排序设计
- 代码的运行环境
- 搜索关键字的显示处理
- 接口异步更新ip信息
- 图片处理
- 项目搭建
- 阅读文档的新方式
- mysql_insert_id并发问题思考
- 行锁注意事项
- 细节注意
- 如何处理用户的输入
- 不可见的字符
- 抽奖
- 时间处理
- 应用开发实战
- python 学习记录
- Scrapy 教程
- Playwright 教程
- stealth.min.js
- Selenium 教程
- requests 教程
- pyautogui 教程
- Flask 教程
- PyInstaller 教程
- 蜘蛛
- python 文档相似度验证
- thinkphp5.0数据库与模型的研究
- workerman进程管理
- workerman网络分析
- java学习记录
- docker
- 笔记
- kubernetes
- Kubernetes
- PaddlePaddle
- composer
- oneinstack
- 人工智能 AI
- 京东
- pc_detailpage_wareBusiness
- doc
- 电商网站设计
- iwebshop
- 商品规格分析
- 商品属性分析
- tpshop
- 商品规格分析
- 商品属性分析
- 电商表设计
- 设计记录
- 优惠券
- 生成唯一订单号
- 购物车技术
- 分类与类型
- 微信登录与绑定
- 京东到家库存系统架构设计
- crmeb
- 命名规范
- Nginx https配置
- 关于人工智能
- 从人的思考方式到二叉树
- 架构
- 今日有感
- 文章保存
- 安全背后: 浏览器是如何校验证书的
- 避不开的分布式事务
- devops自动化运维、部署、测试的最后一公里 —— ApiFox 云时代的接口管理工具
- 找到自己今生要做的事
- 自动化生活
- 开源与浆果
- Apifox: API 接口自动化测试指南