最近工作总结(29)

2019/07/01 Work

WaitGroup 不能被拷贝传递

在主 goroutine 中 Add(delta int) 索要等待goroutine 的数量。 在每一个 goroutine 完成后 Done() 表示这一个goroutine 已经完成,当所有的 goroutine 都完成后,在主 goroutine 中 WaitGroup 返回返回。

func main(){
    var wg sync.WaitGroup
    var urls = []string{
        "http://www.golang.org/",
        "http://www.google.com/",
    }
    for _, url := range urls {
        wg.Add(1)
        go func(url string) {
            defer wg.Done()
            http.Get(url)
        }(url)
    }
    wg.Wait()
}

在Golang官网中对于WaitGroup介绍是A WaitGroup must not be copied after first use,在 WaitGroup 第一次使用后,不能被拷贝

应用示例:

func main(){
 wg := sync.WaitGroup{}
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(wg sync.WaitGroup, i int) {
            fmt.Printf("i:%d", i)
            wg.Done()
        }(wg, i)
    }
    wg.Wait()
    fmt.Println("exit")
}

运行:

i:1i:3i:2i:0i:4fatal error: all goroutines are asleep - deadlock!

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0xc000094018)
        /home/keke/soft/go/src/runtime/sema.go:56 +0x39
sync.(*WaitGroup).Wait(0xc000094010)
        /home/keke/soft/go/src/sync/waitgroup.go:130 +0x64
main.main()
        /home/keke/go/Test/wait.go:17 +0xab
exit status 2

它提示所有的 goroutine 都已经睡眠了,出现了死锁。这是因为 wg 给拷贝传递到了 goroutine 中,导致只有 Add 操作,其实 Done操作是在 wg 的副本执行的。

网络发包阻塞的原因

来于得到吴军《信息论40讲》: 发送方于是马上把那些包重新发送,结果原来的包还没有发完,现在又要多发很多包,网络就变得更加拥堵,最后无论是发送方还是接收方都会锁死在那里。 你有时打开一个网页,刚刚显示了头上10%的内容就再也打不开下面的内容了。你就在想,即便是网速很慢,只有56K的带宽,等待时间长一点也该传完了吧。 其实不是,因为在网络的某一处信道的容量难以满足传输率的要求后,你的计算机作为接收方很长时间没有收到某个包,就无法发出接收完成的信息,传送信息的服务器就不断重新传输那些没有得到接收确认的数据包。传输就永远无法完成了。

思考如何能够增加个人的信息带宽容量?无论是学习过程中,生活上,与人交往上等等

docker 容器服务的自动重启

  • 查看容器的重启次数: docker inspect -f “” my-container
  • 获取上一次容器重启时间: docker inspect -f “” my-container
  • 设置容器服务always自动重启: docker run –restart=always my-container-server
  • 设置容器服务自动重启策略: docker run –restart=on-failure:10 my-container-server

redis配置登入密码

配置文件redis.conf增加: requirepass 123456

redis-cli: config set requirepass 123456 这样不用重启也能增加密码,并且redis重启可以读取redis.conf中的配置内容

127.0.0.1:6379> keys *
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth 123456
OK

GOPATH 还是vendor

一个加载配置文件内容的模块包, 有两个方法使用,一个是load方法,只需要在初始的时候调用一次,将配置文件内容加载到全局变量中,另一个是getkey方法,获取对应的配置值。有两个包中用到了配置文件,一个是main,一个是另一个包。main的init方法调用了load,在main处正常获得了配置值,而在另一个包获得的是nil值。代码逻辑上没有错,最后发现了,main出调用的config模块是加载自GOPATH的,而另一个包中调用的config模块加载自vendor,由于另一个包没有调用load方法,所以全局变量中的map值是空的,所以导致了获得的配置值是nil

原因:没有从GOPATH/src进入到该项目进行build,从GOPATH/src 目录进去到该项目文件夹后,再进行build,就会都以vendor的包为加载优先了

vendor和GOPATH谁优先使用,GOPATH优先使用

如果一个包在vendor和GOPATH下面都存在那么谁会优先使用呢。 结论是:

优先使用vendor目录下面的包。 如果vendor下面没有搜索到,再搜索GOPATH下面的包。 要么完整使用vendor下面的包,要么完整使用GOPATH下面的包,不会混合使用: 假如一个函数定义再GOPATH下面的包里,而没有定义在vendor路径下的同名包里,那么调用者就会报函数未定义错误,因为调用者如果找到有vendor路径下面的包,就不会去找GOPATH下面的包了。

高效能人士的七个习惯

1、积极主动–个人愿景的原则,即采取主动,为自己过去、现在及未来的行为负责,并依据原则及价值观,(而非情绪或外在环境)来下决定,创造改变,积极面对一切;

2、以终为始–自我领导的原则,个人、团队和组织在做任何计划时,均先拟出愿景和目标,并据此塑造未来,全心投注于自己最重视的原则、价值观、关系及目标之上;

3、要事第一–自我管理的原则,即实质的创造,是你的目标、愿景、价值观及要事的组织与实践;

4、双赢思维–人际领导的原则,双赢思维是一种基于互敬、寻求互惠的思考框架与心意,鼓励我们解决问题,并协助个人找到互惠的解决办法,是一种信息、力量、认可及报酬的分享;

5、知彼解己–移情沟通的原则,当我们改变以回答的心态,而以了解对方的心态去聆听别人,便能开启真正的沟通,增进彼此关系,知彼需要仁慈心,解己需要勇气,能平衡两者,则可大幅提升沟通的效率;

6、统合综效–创造性合作的原则,统合综效是创造第三种选择,既非按照我的方式,亦非你的方式,而是第三种远胜过个人之见的办法,它是互相尊重的成果,使整体获得一加一大于二的成效。

7、不断更新–平衡的自我更新的原则,在四个基本生活方面,即生理、社会、情感、心智中,不断更新自己,这个习惯提升了其它六个习惯的实施效率。

curl cip.cc 得到服务器的外网IP地址信息

重复两次注册了 driver MySQL 会报错

panic: sql: Register called twice for driver mysql
goroutine 1 [running]:
database/sql.Register(0x14ba2ae, 0x5, 0x1549280, 0x189a258)
	/usr/local/go/src/database/sql/sql.go:51 +0x189
github.com/go-sql-driver/mysql.init.0()
	/github.com/go-sql-driver/mysql/driver.go:161 +0x5c

验证码的作用

能够在一定程度上防止循环暴力匹配,得到信息

一个错误的SQL语句可能不报错且导致全表查询

select * from person where  name = "xxx" like '%xxx%' limit 10;

快速记大小端的区别

一段连续的内存:起始地址start和结束地址end

  • 大端模式: 位权大的的进制数值在start地址开始,位权大的排列在位权小的字节之前
  • 小端模式: 位权小的的进制数值在start地址开始,位权大的排列在位权小的字节之后

Redis Cluster Config 配置例子

https://juejin.im/post/5b625b9be51d4519956759d0

主从复制功能的详细步骤可以分为7个步骤:

  • 设置主服务器的地址和端口
  • 建立套接字连接
  • 发送PING命令
  • 身份验证
  • 发送端口信息
  • 同步
  • 命令传播

全量重同步的步骤如下

  • 主节点收到从服务器的全量重同步请求时,主服务器便开始执行bgsave命令,同时用一个缓冲区记录从现在开始执行的所有写命令。
  • 当主服务器的bgsave命令执行完毕后,会将生成的RDB文件发送给从服务器。从服务器接收到RDB文件时,会将数据文件保存到硬盘,然后加载到内存中。
  • 主服务器将缓冲区所有缓存的命令发送到从服务器,从服务器接收并执行这些命令,将从服务器同步至主服务器相同的状态。 ``` info replication 可用查看集群Info

192.168.17.103:6379> slaveof 192.168.17.101 6379 OK 角色已经变成从服务器


#### config

################################# REPLICATION #################################

slaveof <主服务器ip> <主服务器端口>

slaveof

masterauth <主服务器Redis密码>

masterauth

当slave丢失master或者同步正在进行时,如果发生对slave的服务请求

yes则slave依然正常提供服务

no则slave返回client错误:”SYNC with master in progress”

slave-serve-stale-data yes

指定slave是否只读

slave-read-only yes

无硬盘复制功能

repl-diskless-sync no

无硬盘复制功能间隔时间

repl-diskless-sync-delay 5

从服务器发送PING命令给主服务器的周期

repl-ping-slave-period 10

超时时间

repl-timeout 60

是否禁用socket的NO_DELAY选项

repl-disable-tcp-nodelay no

设置主从复制容量大小,这个backlog 是一个用来在 slaves 被断开连接时存放 slave 数据的 buffer

repl-backlog-size 1mb

master 不再连接 slave时backlog的存活时间。

repl-backlog-ttl 3600

slave的优先级

slave-priority 100

未达到下面两个条件时,写操作就不会被执行

最少包含的从服务器

min-slaves-to-write 3

延迟值

min-slaves-max-lag 10

```

线上数据库操作要万分小心

在线上数据库进行写操作,这是最不合适的方式,能通过接口,脚本或管理后台操作,才是好的选择

缓存穿透、缓存雪崩

缓存击穿表示恶意用户模拟请求很多缓存中不存在的数据,由于缓存中都没有,导致这些请求短时间内直接落在了数据库上,导致数据库异常。这个我们在实际项目就遇到了,有些抢购活动、秒杀活动的接口API被大量的恶意用户刷,导致短时间内数据库超时 重要的接口一定要做好限流策略,防止用户恶意刷接口,同时要降级准备,当接口中的某些服务不可用时候,进行熔断,失败快速返回机制

布隆过滤器:bloomfilter就类似于一个hash set,用于快速判某个元素是否存在于集合中,其典型的应用场景就是快速判断一个key是否存在于某容器,不存在就直接返回

缓存雪崩问题: 缓存在同一时间内大量键过期(失效),接着来的一大波请求瞬间都落在了数据库中导致连接异常

方案1、也是像解决缓存穿透一样加锁排队,实现同上;

方案2、二级缓存:建立备份缓存,缓存A和缓存B,A设置超时时间,B不设值超时时间,先从A读缓存,A没有读B,并且更新A缓存和B缓存;

方案3、设置缓存超时时间的时候加上一个随机的时间长度,比如这个缓存key的超时时间是固定的5分钟加上随机的2分钟,酱紫可从一定程度上避免雪崩问题

https 只剩下域名端口和 User-Agent,其他都加密了,连 URI 都加密了

Search

    Table of Contents