\

完整性约束

一、完整性约束的概念 ​ 保证授权用户对数据库所做的修改不会破坏数据的一致性。 ​ 因此,完整性约束 防止的是对数据的意外破坏。 二、完整性约束分为三类,包括: ​ \1. 域完整性 :是指给定列的取值范围(即输入的有效性) ​ \2. 实体完整性 :规定表中的每一行在表中是唯一的一个实体(实体就是一条记录) ​ \3. 参照完整性 :保持主外键之间的参照规则。它保证的是表之前数据的一致性,防止了数据丢失或无意义的数据在数据库中扩散。 ​ 4.用户定义完整性:不同的关系数据库系统根据其应用环境的不同,往往还需要一些特殊的约束条件。用户定义的完整性是针对某个特定关系数据库的约束条件,它反映某一具体应用必须满足的语义要求。(就是根据特定的业务,用户自定义的规则) 三、完整性约束的类型 ​ \1. 主键约束(PRIMARY KEY):要求主键列 数据唯一,并且不允许为空,PRIMARY KEY = UNIQUE + NOT NULL。主键可以包含表的一列或多列。你定义的主键包含多列时,你只能在表级定义。 ​ # 在表级定义主键约束 ​ CREATE TABLE student ( ​ sno NUMBER(3), ​ same VARCHAR2(15), ​ gender CHAR(3) DEFAULT ‘男’, ​ age NUMBER(2), ​ CONSTRAINTS pk_student PRIMARY KEY (sno,sname) ​ ); ​ # 在列级定义主键约束 ​ CREATE TABLE student (

Goroutine 执行顺序

package main import ( "fmt" ) func sum(s []int,c chan int){ num:=0 for _,v:=range s { num+=v } c<-num } func main(){ s:=[]int{7,2,8,-9,4,0} c:=make(chan int,0) go sum(s[len(s)/2:],c) go sum(s[:len(s)/2],c) //y,x:=<-c,<-c x:=<-c y:=<-c fmt.Println(x,y,x+y) } 输出: 17 -5 12 值得我好奇的是,这个输出顺序是固定的,按我之前的理解来讲,我认为这个顺序应该是变化的,就是可能先输出-5,接着再输出17,也可能先输出17,再输出-5这种顺序,我反复运行好多次,结果很出乎我的意料/ 下面来解释一下原因(摘自网络) go 关键字只是一个语法糖,可以认为 go func() 只是创建了一个 待被执行任务(G),for 循环只能保证三个任务的创建顺序是 G(a) -> G(b) -> G(c),但三个任务很可能会被分配到不同的cpu core上执行(go 的运行时调度器来分配)。所以三个任务的执行顺序是不确定的。 但是比较奇妙的是,一般情况下「在同一个 goroutine 中创建的多个任务」中最后创建那个任务最可能先被执行。原因的话就要看 go 的实现细节了:简单来说,同一 goroutine 中三个任务被创建后 理论上会按顺序 被放在同一个任务队列,但实际上最后那个任务会被放在 next(下一个要被执行的任务的意思)的位置,所以优先级最高,最可能先被执行。剩下的两个任务如果 go 运行时调度器发现有空闲的 core,就会把任务偷走点,让别的 core 执行,这样才能充分利用多核,提高并发能力。

构建容器

根据 dockerfile 文件构建镜像,进而构建容器 构建镜像 先写好一个dockerfile文件,然后命令行执行: $ docker image build --file <path_to_dockerfile> --tag <repository>:<tag> . 通常不会加 --file 参数,就直接: $ docker image --tag <repostory>:<tag> . 注意最后面这个 · 表示此命令在当前文件夹中构建镜像 构建容器 启动容器 $ docker container run -d --name <container_name> -p <container_port>:<宿主机port> <repostory>:<镜像tag> -v 停止/删除 容器 $ docker container stop <container1_tag> <container2_tag> $ docker container <container1_tag> <container2_tag> 使用基础镜像去构建容器 不推荐这种做法 拉取基础镜像 ```shell $ docker image pull :<版本号,一般latest> $ docker image pull ubuntu:latest

细说三次握手与四次挥手

seq, ack, fin seq: 确认序列 ack: 确认包 fin: 断开连接包 三次握手 客户端先发送 SYN=x 请求建立连接 服务器返回 ACK=x+1,SYN=Y 客户端再回复 ACK=Y+1 建立连接成功 为什么是三次握手? 假设 client 端向 server 端发送了一个请求报文(没有丢失的报文),但是不幸在网络节点中被滞留了,以至于延误了,直到 client 端释放了该连接之后才抵达 server 端, 如果在没有第三次握手的前提下,那么 server 端会直接建立连接成功,但是 client 端这个连接对于它来讲已经失效了,所以它不会用这个连接去跟 server 进行沟通了,也就是说它不会再发任何数据给 server 端了,那么这样导致的就是呢一次连接的浪费 如果有第三次握手呢,server 端对 client 传过来的这个报文请求会向其发送 ACK 和 SYN,等待 client 回复 ACK 确认消息,该连接才会被认为是有效的,这样一来,就不会出现浪费资源的情况。 从而证明三次握手是必要的! 第二次握手证明 client=>server 是没问题的 第三次握手证明 server=>client 是没问题的 TCP 是全双工通信的,由于网络通信是不可靠的,所以通过三次握手可以「最低限度」的确认全双工通信通道 四次挥手 想要断开连接的一方 向 对方 发送一个 FIN 数据包,对方收到之后回复一个 ACK ,在间隔一段时间之后,再发送 FIN, 然后 主动断开的一方 回复 对方 一个 ACK

Linux基础命令

修改权限 #ls命令输出的前两个格式 [d/-/l] [rwx][rwx][rwx] #d说明是文件夹,-说明是文件,l说明是一个链接文件 #第二个是部分是三组权限,从左到右分别对应「拥有者权限」、「所属群组权限」、「其他人权限」 #r是读权限,w是写权限,x是可执行权限,如果没有对应的权限则用-占位 #修改.baserc文件的权限 #第一种数字类型改变权限 #r:4,w:2,x:1; 相加占位 chmod 755 .baserc #第二种符号类型改变权限 #u是拥有者,g是群组,o是其他人,a是上述三个所有 chmod u=rwx,go=rx .baserc #为所有加上可写权限 chmod a+w .baserc #为所有删除可写权限 chmod a-w .baserc 对于纯文件来讲,「写」这个权限的意义是只针对其内容进行修改操作,而不针对其本身的修改(比方说删除这个权限) 对于目录文件来讲,「写」这个权限的意义就不一样了,它针对的是它下面所有的文件(包括目录文件,纯文件)的修改,注意,是对文件的修改