1 |
|
linux/cat
1 | # << EOF 不支持缩进, 必须顶格些 |
date
1. 参数
-d
2. 时间格式
1 | %a 当前locale 的星期名缩写(例如: 日, 代表星期日) |
1 | echo `date '+%Y-%m-%d %H:%M:%S'` |
sudo
1 | # 非交互式输入密码 |
konsole
Konsole 好用是因为可以修改复制黏贴的快捷键, 这样操作起来比较方便.
1. 修改 Tab title
1 | # 本地 Tab 格式 : %d : %n |
2. 获取 Session ID
1 | echo $KONSOLE_DBUS_SESSION |
3. 获取 Konsole 的参数配置
1 | konsole --list-profile-properties |
notify-send
1. 安装
1 | sudo apt install -y libnotify-bin |
2. 使用
1 | # 向桌面发送通知 |
xargs
1. 参数
-
-n
多行输出1
2每行输出3个元素
cat test.txt | xargs -n 3 -
-d
选项可以自定义一个定界符1
echo "nameXnameXnameXname" | xargs -d X
-
I
指定一个替换字符串1
2cat arg.txt | xargs -I {} ./sk.sh -p {} -l
find . -name 'teskechers_crmep-benefit*' | xargs -I {} grep 'T4LP75KKL44T5' {}/run/latests/stdout
drds
https://help.aliyun.com/product/29657.html?spm=a2c4g.11186623.3.1.l1lX2S
Lock conflict 报错处理
DRDS 执行 DDL 操作先会加库级锁, 操作完后再释放掉.
KILL DDL 操作很可能会导致该锁没有释放, 此时再执行 DDL 会有以下报错:
Lock conflict , maybe last DDL is still running
此时执行 RELEASE DBLOCK 释放该锁即可.
指令取消及锁释放后, 选择业务低谷甚至停止期间, 重新执行该 DDL.
分布式事务
分布式事务指事务的参与者, 支持事务的服务器, 资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上.
简单的说, 就是一次大的操作由不同的小操作组成, 这些小的操作分布在不同的服务器上, 且属于不同的应用, 分布式事务需要保证这些小操作要么全部成功, 要么全部失败.
1. CAP
CAP 是指以下 3 个属性:
- 一致性 Consistency
数据的一致性 - 可用性 Availability
服务的可用性 - 分区容忍性 Partition tolerance
在网络异常的情况下, 服务能容忍网络分区之间的数据不一致时
CAP 理论指出分布式系统无法同时支持以上 3 个属性, 最多只能保证支持 2 个属性.
对于分布式系统, 必然要支持分区容忍性, 设计者需要在一致性与可用性之间权衡.
2. BASE
BASE 就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案, 也称柔性事务.
BASE是下面三个术语的缩写:
- 基本可用 Basically Available
分布式系统在出现故障时, 允许损失部分可用功能, 保证核心功能可用. - 软状态 Soft state
允许系统中存在中间状态, 这个状态不影响系统可用性, 这里指的是 CAP 中的不一致. - 最终一致 Eventually consistency
最终一致是指经过一段时间后, 所有节点数据都将会达到一致.
BASE 理论的核心思想是: 即使无法做到强一致性, 但每个应用都可以根据自身业务特点, 采用适当的方式来使系统达到最终一致性.
它完全不同于 ACID 的强一致性模型, 而是通过牺牲强一致性来获得可用性, 并允许数据在一段时间内是不一致的, 但最终达到一致状态.
但同时, 在实际的分布式场景中, 不同业务单元和组件对数据一致性的要求是不同的, 因此在具体的分布式系统架构设计过程中, ACID 特性和 BASE 理论往往又会结合在一起.
3. XA
XA 由 X/Open 组织提出的处理分布式事务的规范.
XA 规范能够允许在一个全局事务中协调多个分散的事务资源.
使用全局事务的应用会有一个或多个资源管理器和一个事务管理器.
- 资源管理器 Resource Manager
用于管理事务资源. 数据库服务就是一个资源管理器. 资源管理还应该具有管理事务提交或回滚的能力. - 事务管理器 Transaction Manager
事务管理器是分布式事务的核心管理者. 事务管理器与每个资源管理器进行通信, 协调并完成事务的处理. 事务的各个分支由唯一命名进行标识.
3.1. 2PC
2PC, 二阶段提交, 2 Phase-Commit
XA 通常采用 2PC.
阶段一为准备(prepare)阶段.
即所有的参与者准备执行事务并锁住需要的资源.
参与者ready时, 向transaction manager报告已准备就绪.
阶段二为提交阶段(commit).
当transaction manager确认所有参与者都ready后, 向所有参与者发送commit命令.
3.2. 3PC
3PC, 三阶段提交
3.3. XA
XA, 是 2PC 的一种实现方式
4. TCC
补偿性事务, Try-Commit-Cancel
5. Paxos
6. 其他
异步处理
幂等 失败, 成功, 处理中
分布式锁
乐观锁
MQ
http://www.tianshouzhi.com/api/tutorials/distributed_transaction/
JTA/XA
7. 思考
解决分布式事务
7.1. 1. 重试
在分布式事务处理中要允许重试, 所以要让事务中的每个操作操作幂等.
对于那些无法将操作转化为幂等操作的, 则无法解决分布式事务的一致性问题.
如 Reids 的 incr() 操作, 再不使用另外一个变量记录操作步骤的情况下, 就无法得知有没有重复操作过
8. Resource
MySQL XA MySQL XA SQL 语法 DTP 参考模型 DTP XA规范https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
https://www.jianshu.com/p/16b1baf015e8
mvp
MVP—-Minimum Viable Product, 简称MVP, 即 最小化可行产品
在市场不确定的情况下, 通过设计实验来快速检验你的产品或方向是否可行.
如果你的假设得到了验证, 再投入资源大规模进入市场;如果没有通过, 那这就是一次快速试错, 尽快调整方向.