分类 编程 下的文章

方案一:

package main

import (
    "fmt"
    "runtime"
    "sync"
    "time"
)

// 定义一个同步等待的组
var wg sync.WaitGroup

// 定义一个Printer函数用于并发
func Printer(a int) {
    time.Sleep(2000 * time.Millisecond)
    fmt.Printf("i am %d\n", a)
    defer wg.Done()
}

func main() {
    // 获取cpu个数
    maxProcs := runtime.NumCPU()
    // 限制同时运行的goroutines数量
    runtime.GOMAXPROCS(maxProcs)
    for i := 0; i < 10; i++ {
        //为同步等待组增加一个成员
        wg.Add(1)
        //并发一个goroutine
        go Printer(i)
    }
    // 阻塞等待所有组内成员都执行完毕退栈
    wg.Wait()
    fmt.Println("WE DONE!!!")
}

- 阅读剩余部分 -

分支合并,有两个选择,一个是 merge,另一个是 rebase

  1. mergerebase 合并后的结果是一模一样的,形象的说,二者是殊途同归。
  2. 使用 rebase 后的 commit 与之前的 commit,它们的 SHA-1 值不同,Git 会把它们看成两次提交。

现在社区中推荐的主流 Git 合作方法,也是利用 Rebase 命令,即 Fork 一个代码库后,保留一个 remote 分支用来跟近主库进度,另开一个 feature 分支来打 patch,当 patch 打好后,在本地同步一下 remote 分支上的代码,保持与主库一致,如果在你打 patch 这段时间,主库发生了变化,那么你就需要在本地预先做一次 rebase 操作,以保证你的改动是构建在主库最新代码之上的。这其实相当与你帮助作者在本地处理好了冲突,这样作者再合并你的代码时候,也就能比较轻松了。换个角度,其实使用 rebase 这个过程也是一个自我检查的过程,可以强制你对改动进行 Review,从而减轻贡献者和所有者之间的工作量。因为没有人比你更熟悉你的代码。

git pull —rebase,这个命令在实际使用中的出场率还是很高的。
我们先从 git pull 说起,git pull 完整的应该是 git fetch + git merge FETCH_HEAD,默认时候 git pull 会先拉取代码,再进行 merge,上面说了使用 merge 会多出一条合并的 commit 以及一条分支线来,如果 commitmerge 频繁的话,可能会出现下图这样的情况,但是 rebase 则不同,其会保持线性,这样提交记录看起来就会整洁许多,使用 rebase 就是这个意思用 git rebase 取代。
git-rebase-1.png

假设有如下分支图:
unmerge1.png

注:Git 分支图中的箭头表示依赖关系,并不是分支发展路线。发展路线和箭头是相反的。也就是图中是从 C1 开始一直发展到 C12 的。

假设要回滚 C10。

第一种解决方案是将 master 回退到 C8,然后将两个特性分支 jk/post-checkoutdb/push-cleanup 合并过来。

git checkout master
git reset --hard [sha_of_C8]
git merge jk/post-checkout
git merge db/push-cleanup

完成之后,分支图如下:
unmerge2.png

- 阅读剩余部分 -

在上传工程到 git 上时,有时候会把本地的一些配置文件传到服务器上,这时你先删除本地,再同步服务器,显然是不合理的。
git 提供了一个好的解决方法,可以直接删除服务器文件,同时不影响本地文件,命令如下:

git rm --cached filename/-r directory
git commit "xxxx"
git push

1.删除服务器文件,本地保留。

git rm --cached useless.log
git commit -m "remove file from remote repository"
git push

此时 github 上已经不存在了

2.删除远程 useless 文件夹,本地保留,一定要注意,删除文件夹要使用 -r 参数。

git rm --cached -r useless
git commit -m "remove directory from remote repository"
git push

单主干
单主干的分支实践(Trunk-based development TBD)在 SVN 中比较流行。Google 和 Facebook 都使用这种方式。trunk 是 SVN 中主干分支的名称,对应到 Git 中则是 master 分支。TBD 的特点是所有团队成员都在单个主干分支上进行开发。当需要发布时,先考虑使用标签tag,即 tag 某个 commit 来作为发布的版本。如果仅靠 tag 不能满足要求,则从主干分支创建发布分支。bug 修复在主干分支中进行,再 cherry-pick 到发布分支。
git-branch-01.png

- 阅读剩余部分 -

之前对 ELKB 环境从 2.4 版本升级到最新的 5.0 稳定版本,发现 kafka 集群运行报错,现在把排查过程记录下。

之前环境:
logstash2.4
logstash-input-kafka-2.0.9
logstash-output-kafka-2.0.5
kafka_2.10-0.8.2.2.tgz

升级后环境:
logstash5.0
logstash-input-kafka-2.0.9
logstash-output-kafka-2.0.5

报错信息:

[2016-11-16T14:35:44,739][ERROR][logstash.inputs.kafka] Unknown setting 'zk_connect' for kafka
[2016-11-16T14:35:44,741][ERROR][logstash.inputs.kafka] Unknown setting 'topic_id' for kafka
[2016-11-16T14:35:44,741][ERROR][logstash.inputs.kafka] Unknown setting 'reset_beginning' for kafka

- 阅读剩余部分 -