泽川的Blog

Welcome! 这是我的第一篇博客 目标及时总结和分享包括但不限于以下内容： 技术总结 行业思考 刷题笔记 职场经验 计划后续会将本地的笔记和记录整理成博客文章发布

选举原理通过阅读etcd提供的Campaign方法，发现选举过程基于了Etcd的几个特性，就可以完成自动选主： MVCC：key存在版本属性，没被创建时版本号为0 CAS操作：结合MVCC，可以实现竞选逻辑，if(version == 0) set(key,value),通过原子操作，确保只有一台机器能set成功； Lease租约：可以对key绑定一个租约，租约到期时没预约，这个key就会被回收； Watch监听：监听key的变化事件，如果key被删除，则重新发起竞选。   流程梳理在Sentinel选主时，核心代码逻辑如下： 首先定义一个了选举接口，可以针对不同的场景实现（在这里只介绍使用etcd方式进行leadership） RunForEletion方法：进行Leader选举 Leader方法：返回Leader节点value值 Stop方法：停止处理   Sentinel结构体定义如下： election：选举接口 leader：bool类型，标识当前sentinel节点是否为leader leadershipCount：leader任期， ...

前言我们的管控项目是按地域部署，为了保证服务高可用，每个管控组件都部署2份，但是同时只有1个(Leader)对外提供服务，当Leader服务挂掉时，我们需要从Follower服务中重新选举一个服务来当Leader，复杂的方式是通过Raft协议去协商，简单点，可以通过分布式锁的思路来做。 而我们的项目就是通过etcd的分布式锁来实现的。在服务启动时，会尝试去进行leader竞争，成为leader的才能对外提供服务。 我在本地实现了个最基础版的leader选举代码   核心思想 所有的Follower服务去竞争同一把锁，并给这个锁设置一个过期时间 只会有一个Follower服务取到锁，这把锁的值就为它的标识，他就变成了Leader服务 其他Follower服务竞争失败后，去获取锁得到的当前的Leader服务标识，与之通信 Leader服务需要在锁过期之前不断的续期，证明自己是健康的 所有Follower服务监控这把锁是否还被Leader服务持有，如果没有，就跳到了第1步   代码演示该段代码实现了基于etcd的分布式leader选举算法，可以协调多个客户端对leade ...

Keeper   Sentinel

复制方式 一主一备是同步物理流复制 RO是异步流复制 当备机宕机后，如果此时主库有写操作，会写等待，此时管控会降为异步流复制模式，并重做备库     设置synchronous_commit参数这个参数用来设置事务提交返回客户端之前，一个事务是否需要等待 WAL 记录被写入磁盘。合法的值是{local,remote_write,remote_apply,on,off} off 级别最低 当数据库事务提交时不需要等待本地 wal buffer 写入 wal 日志，立刻向客户端返回成功 local 当事务提交时，写入本地磁盘即可 remote_write 表示流复制主库提交事务时，需等待备库接收主库发送的wal日志流并写入备节点操作系统缓存中，之后向客户端返回成功，这种情况下备库出现异常关闭时不会有已传送的wal日志丢失风险，但备机OS异常宕机就有已传送的wal丢失风险 备机只需写入缓存，不需要落盘 remote_apply 级别最高 表示流复制主库提交事务时，需等待备库接收主库发送的wal流并写入wal文件，同时备库已经完成 ...

什么是幂等性什么是幂等性？一次和多次请求某一个资源，对资源本身所产生的的影响均与一次执行的影响相同。 幂等性是系统服务对外的一种承诺，承诺只要调用接口成功了，多次调用对系统的影响是一致的。   幂等性与重复提交比较幂等性 更多使用的情况是第一次请求知道结果，但是由于网络抖动或连接超时等情况未进行正常返回，在这种情况下系统自动再次发起请求，其目的是确认第一次是否请求完成。 重复提交 更多使用的情况是第一次请求成功或请求结果暂未返回的情况下，人为的进行多次操作。   为什么需要保证接口的幂等性？接口的幂等性非常重要，因为在实际的应用中，接口可能会被调用多次，例如在网络不稳定或者客户端重试的情况下。如果接口没有保证幂等性，那么就会导致数据或者业务逻辑出现不一致的情况。 例如，如果一个非幂等性的接口被调用两次，第一次调用时创建了一个资源，第二次调用时又创建了一个相同的资源，这样就会导致资源数量不一致。   哪些场景需要保证幂等性前端重复提交表单：在填写一些表单数据的时候，用户点击提交按钮，但是由于网络波动导致服务端没有及时给用户返回提交成功的响应，致使用户认为没有 ...

背景移动互联网发展至今，移动支付占据了90%以上的交易量，传统的金融IT架构面临着海量的高并发响应、处理速度以及安全性的挑战。金融行业的数据库市场，尤其是银行的核心交易系统，一直是 Oracle、DB2 这类美国传统商业数据库的天下，从银行系统的角度来看，所承担的业务量将是海量式的增长，同时也不可避免带来金融行业数据安全、业务安全方面的风险，传统数据库显然不满足需求了。 政策随着国家有关部门近年来陆续出台相关政策指导文件，推动探索安全可控的金融科技产品，加强银行业信息安全建设，由新型分布式数据库替代传统集中式架构，成为金融级数据库市场的主流趋势。央行19年发布《金融科技(FinTech)发展规划(2019-2021年)》也强调，加强分布式数据库研发应用，为分布式数据库在金融领域的全面应用探明路径。国内众多金融政企机构纷纷开始探索改造原有IT系统，对国产化数据库的需求日益强烈。 云时代在数字经济时代的今天，各行各业都在加速上云 ，金融业也行驶在数字化转型的浪潮中。在其背后，数据库承载着金融机构的核心数据，是金融科技业务创新的基础和底座，阿里云、腾讯云、华为云三家中国云计算厂商巨头纷纷推出 ...

原理基于 (隐藏字段 + undolog + readView)来实现MVCC的 undolog ： 修改数据时，将该记录写入到版本链中，undolog， 每次放在头部。   行隐藏字段： db_trx_id：事务ID，全局唯一 roll_pointer 版本链指针 ReadView中的统计值： m_ids 当前活跃的事务集合（所有未提交的事务） min_trx_id m_ids中最小的。即最小的活跃事务ID max_trx_id 版本链头的事务+1。max_trx_id并不是m_ids中的最大值，事务ID是递增分配的。比方说现在有id为1，2，3这三个事务，之后id为3的事务提交了。那么一个新的读事务在生成ReadView时，m_ids就包括1和2，min_trx_id的值就是1，max_trx_id的值就是4 creator_trx_id 当前创建这个视图的事务ID   根据上图，当前事务ID为201时，统计值如下： m_ids = [90,100, 200] min_tx_id = 90 max_tx_id = 200 + 1 = ...

一、Master配置1、修改postgresql.conf文件 123456listen_addresses = '*' #监听的IP地址wal_level = hot_standby #启用热备模式synchronous_commit = on #开启同步复制max_wal_senders = 2 #同步最大的进程数量wal_sender_timeout = 60s #流复制主机发送数据的超时时间max_connections = 100 #最大连接数，从库的max_connections必须要大于主库的 2、创建同步账号，用于流复制 1create user replica with password '123456' replication; 3、修改pg_hba.conf，允许从库地址通信 12host replication replica 主机ip/32 md5 #在master上可以执行pg_basebackuphost replication replica 备机ip/32 md5 #s ...