log

写在前面的话 本文所有Kafka原理性的描述除特殊说明外均基于Kafka 1.0.0版本。 为什么要提供事务机制 Kafka事务机制的实现主要是为了支持 Exactly Once 即正好一次语义 操作的原子性 有状态操作的可恢复性 Exactly Once 《 Kafka背景及架构介绍 》一文中有说明Kafka在0.11.0.0之前的版本中只支持 At Least Once 和 At Most Once 语义，尚不支持 Exactly Once 语义。 但是在很多要求严格的场景下，如使用Kafka处理交易数据， Exactly Once 语义是必须的。我们可以通过让下游系统具有幂等性来配合Kafka的 At Least Once 语义来间接实现 Exactly Once 。但是： 该方案要求下游系统支持幂等操作，限制了Kafka的适用场景 实现门槛相对较高，需要用户对Kafka的工作机制非常了解 对于Kafka Stream而言，Kafka本身即是自己的下游系统，但Kafka在0.11.0.0版本之前不具有幂等发送能力 因此，Kafka本身对 Exactly Once 语义的支持就非常必要。 操作原子性 操作的原子性是指，多个操作要么全部成功要么全部失败，不存在部分成功部分失败的可能。 实现原子性操作的意义在于： 操作结果更可控，有助于提升数据一致性 便于故障恢复。因为操作是原子的

一.redo log 使用原因 在 MySQL 里有这个问题，如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程 IO 成本、查找成本都很高 其实就是 MySQL 里经常说到的 WAL 技术，WAL 的全称 是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘 当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做 原理 InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文 件的大小是 1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末 尾就又回到开头循环写，如上面这个图所示。 write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件 开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录 更新到数据文件。 write pos 和 checkpoint 之间的是“粉板”上还空着的部分，可以用来记录新的操作。如 果 write pos 追上 checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下

物化视图是一种特殊的物理表，“物化”(Materialized)视图是相对普通视图而言的。普通视图是虚拟表，应用的局限性大，任何对视图的查询，Oracle都实际上转换为视图SQL语句的查询。这样对整体查询性能的提高，并没有实质上的好处。 1、物化视图的类型：ON DEMAND、ON COMMIT 二者的区别在于刷新方法的不同，ON DEMAND顾名思义，仅在该物化视图“需要”被刷新了，才进行刷新(REFRESH)，即更新物化视图，以保证和基表数据的一致性；而ON COMMIT是说，一旦基表有了COMMIT，即事务提交，则立刻刷新，立刻更新物化视图，使得数据和基表一致。 2、ON DEMAND物化视图 物化视图的创建本身是很复杂和需要优化参数设置的，特别是针 对大型生产数据库系统而言。但Oracle允许以这种最简单的，类似于普通视图的方式来做，所以不可避免的会涉及到默认值问题。也就是说Oracle给物 化视图的重要定义参数的默认值处理是我们需要特别注意的。 物化视图的特点： (1) 物化视图在某种意义上说就是一个物理表(而且不仅仅是一个物理表)，这通过其可以被user_tables查询出来，而得到佐证； (2) 物化视图也是一种段(segment)，所以其有自己的物理存储属性； (3) 物化视图会占用数据库磁盘空间，这点从user_segment的查询结果，可以得到佐证； 创建语句

Oracle之物化视图 近期根据项目业务需要对oracle的物化视图有所接触，在网上搜寻关于这方面的资料，便于提高，整理内容如下： 物化视图是一种特殊的物理表，“物化”(Materialized)视图是相对普通视图而言的。普通视图是虚拟表，应用的局限性大，任何对视图的查询，Oracle都实际上转换为视图SQL语句的查询。这样对整体查询性能的提高，并没有实质上的好处。 1、物化视图的类型：ON DEMAND、ON COMMIT 二者的区别在于刷新方法的不同，ON DEMAND顾名思义，仅在该物化视图“需要”被刷新了，才进行刷新(REFRESH)，即更新物化视图，以保证和基表数据的一致性；而ON COMMIT是说，一旦基表有了COMMIT，即事务提交，则立刻刷新，立刻更新物化视图，使得数据和基表一致。 2、ON DEMAND物化视图 物化视图的创建本身是很复杂和需要优化参数设置的，特别是针 对大型生产数据库系统而言。但Oracle允许以这种最简单的，类似于普通视图的方式来做，所以不可避免的会涉及到默认值问题。也就是说Oracle给物 化视图的重要定义参数的默认值处理是我们需要特别注意的。 物化视图的特点： (1) 物化视图在某种意义上说就是一个物理表(而且不仅仅是一个物理表)，这通过其可以被user_tables查询出来，而得到佐证； (2) 物化视图也是一种段(segment)

1.compute节点上安装Ocata，openstack-nova-compute组件无法安装上，报错Requires: qemu-kvm-rhev >= 2.9.0 解决方法： 在compute节点上执行： echo " [Virt] name=CentOS-$releasever - Base baseurl=http://mirrors.163.com/centos/7.6.1810/virt/x86_64/kvm-common/ gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 ">> /etc/yum.repos.d/CentOS-Base.repo 再次执行安装即可： yum -y install openstack-selinux python-openstackclient yum-plugin-priorities openstack-nova-compute openstack-utils ntpdate 2.主机节点启动后，如果dashboard中获取卷失败 排查、解决办法： controller1节点上 systemctl status openstack-cinder-api.service openstack-cinder-scheduler.service

原文: 高性能MySQL之基础架构 一、背景 当你手中抓住一件东西不放时，你只能拥有一件东西，如果你肯放手，你就有机会选择更多。与其在别人的生活里跑龙套，不如精彩做自己。人无所舍，必无所成。跌倒了，失去了，不要紧，爬起来继续风雨兼程，且歌且行。 为什么我们需要先学习MYSQL的基础架构先呢？ 原因很简单，当我们需要了解一件事物的时候，我们只有站在宏观的层面，才能层层剥丝抽茧的去理解问题。举个例子，我们要看一个框架的源码，一开始就想进去研究，却发现找不着北，原因很简单，因为我们没有鸟瞰全貌，我们根本不知道入口在哪里。因此我们学习MYSQL的时候也是这样。先从高纬度理解问题，最后看到里面有哪些组件，一层层的拆解，这样让我们对mysql有更深入的理解。废话不多说，我们先看总体的逻辑架构图，如下所示。 二、Mysql总体逻辑架构 从图中不难看出，不同的存储引擎共用一个Server层，也就是从连接器到执行器的部分。可以看到Server层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如触发器、视图等。 需要主意的是存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB

第一步模拟环境:``` echo song{01..40}|xargs -n1>/tmp/file.log 方法1: head -30 /tmp/file.log|tail -11 方法2: sed -n '20,30p' /tmp/file.log 方法3: sed '20,30!d' /tmp/file.log 方法4: awk 'NR==20,NR==30' /tmp/file.log 方法5: awk 'NR>=20 && NR<=30' /tmp/file.log 方法6: grep -n "" /tmp/file.log |grep -A 10 "^20:" 20 :song20 21:song21 22:song22 23:song23 24:song24 25:song25 26:song26 27:song27 28:song28 29:song29 30:song30 方法7: grep -n "" /tmp/file.log |grep -B 10 "^30:" 20:song20 21:song21 22:song22 23:song23 24:song24 25:song25 26:song26 27:song27 28:song28 29:song29 30 :song30 方法8: grep -n "" /tmp/file.log |grep -C 5

查看版本 $ git log test.txt commit ffe1abd0d4318b5b92fcbf010001422630615c74 (HEAD -> master) Author: aimer <15267840622@163.com> Date: Thu Mar 5 17:38:59 2020 +0800 测试1 commit 6f654886ced05d0d8fadc023345d0d8dc1a1dd3b Author: aimer <15267840622@163.com> Date: Thu Mar 5 16:22:44 2020 +0800 aa 版本对比 $ git diff 6f65 ffe1 test.txt diff --git a/test.txt b/test.txt index 7ec9a4b..0363275 100644 --- a/test.txt +++ b/test.txt @@ -1 +1 @@ -aa \ No newline at end of file +aaasddasd \ No newline at end of file 版本查看 $ git log --pretty=oneline ffe1abd0d4318b5b92fcbf010001422630615c74 (HEAD -> master) 测试1

习惯了使用 windows 的计划任务， 使用 linux 中的 crontab 管理定时任务 时很不适应 。 所以把基本的用法总结如下。 创建一个简单的定时任务 每分钟输出一次当前的时间，输出到用户家目录下的 time.log 文件中。 $ crontab -e * * * * * echo `date` >> /home/xxx/time.log crontab 程序的路径为 /usr/bin/crontab。 每个用户的定时任务可以在 /var/spool/cron/crontabs/ 目录下查询到。 需要使用root权限才能进入这个目录。每个以用户名命名的文件中记录着该用户的定时任务。 注意，不要使用 vi 直接编辑这些文件。 cron 运行的每一项工作都会被纪录到 /var/log/cron 这个登录档中，但是 Ubuntu 默认关闭了cron 的 log。 打开的方式为：打开 rsyslog 服务的配置文件 $ sudo vim /etc/rsyslog.d/50-default.conf 将下面一行中前面的注释符去掉 cron.* /var/log/cron.log 重启 rsyslog $ sudo service rsyslog restart 现在就可以看到 /var/log/cron 文件了，查看该文件是解决定时任务出错的重要途径。 控制用户运行定时任务

论文原文 Bag of Tricks for Efficient Text Classification 论文信息 EACL2017 论文解读 Hytn Chen 更新时间 2020-02-23 文本分类相关方法 用作文本分类的卷积神经网络，有多个使用流程示意图如下 1维卷积 堆卷积（Goldberg Book） 延迟CNN（Kalchbrenner et al. 2016） 动态CNN 详见这篇文章解读 总结一下，CNN在文本分类中担任的主要角色就是encoding文本，之后可以用分类器解决分类的问题。CNN主要问题就是训练相对较慢，从而就限制了CNN不能在非常大的数据集上使用。 论文提出的模型 模型结构图如下 简单来讲就是 文本表征+线性模型 ，这里的文本表征由n-gram，词查找表以及CBOW组成，线性模型由多层softmax和rank constraint组成（实现参数共享的效果）。 输入层 ：先看n-gram表征，很简单理解，假设一句话有N个词，1-gram就是单个词为一组，一共可以有N组；2-gram就是两个词为一组的排列组合，一共可以有 N ( N − 1 ) 2 \frac{N(N-1)}{2} 2 N ( N − 1 ) ​ 组，如果再多那字典（要索引到具体组别，一个组别一个序号）的维度就呈指数增长了，因此文中使用了哈希字典的方式来避免这样的情况发生（把所有的n