Gogs: PR-5322

Add new Dockerfile.docker-ce for docker-ce(>=v17.06) to build Gogs’s docker image

Docker-CE can be given to a new build stage by adding AS name to the FROM instruction sine release version of v17.06. The Dockerfile’s FROM instruction like below:

FROM

FROM <image> [AS <name>]

Or

FROM <image>[:<tag>] [AS <name>]

Or

FROM <image>[@<digest>] [AS <name>]
  • Optionally a name can be given to a new build stage by adding AS name to the FROM instruction. The name can be used in subsequent FROM and COPY --from=<name|index> instructions to refer to the image built in this stage.

Find Docker-ce official document here.

Gogs: PR-5262

Fix make build failure when enviroment of GOPATH have multiple items

[alimy@rover gogs]$ pwd
/home/alimy/art/arg/src/github.com/gogs/gogs
[alimy@rover gogs]$ echo $GOPATH
/home/alimy/art/ago:/home/alimy/art/arg
[alimy@rover gogs]$ make
go install "-v" -ldflags '-X "github.com/gogs/gogs/pkg/setting.BuildTime=2018-06-04 06:17:19 UTC" -X "github.com/gogs/gogs/pkg/setting.BuildGitHash=c08aab90ec696b7fcc56b8da0a468e74d266b89e"' -tags '""'
cp '/home/alimy/art/ago:/home/alimy/art/arg/bin/gogs' .
cp: cannot stat '/home/alimy/art/ago:/home/alimy/art/arg/bin/gogs': No such file or directory
Makefile:36: recipe for target 'build' failed
make: *** [build] Error 1

In this scene GOPATH have two item (/home/alimy/art/ago and /home/alimy/art/arg) and gogs source is not in first GOPATH items, when excecute go install ... will install to path that contain the source of gogs’s GOPATH items. when cp gogs file back will occur error like above. this patch fixed this problem.

[alimy@rover gogs]$ echo $GOPATH
/home/alimy/art/ago:/home/alimy/art/arg
[alimy@rover gogs]$ pwd
/home/alimy/art/arg/src/github.com/gogs/gogs
[alimy@rover gogs]$ echo ${PWD%%src*}
/home/alimy/art/arg/

NewSQL: 分布式数据库TiDB、CockroachDB

TiDB

TiDB 开源分布式 NewSQL 关系型数据库 TiDB 是新一代开源分布式 NewSQL 数据库,模型受 Google Spanner / F1 论文的启发,实现了自动的水平伸缩,强一致性的分布式事务,基于 Raft 算法的多副本复制等重要 NewSQL 特性。TiDB 结合了 RDBMS 和 NoSQL 的优点,部署简单,在线弹性扩容和异步表结构变更不影响业务, 真正的异地多活及自动故障恢复保障数据安全,同时兼容 MySQL 协议,使迁移使用成本降到极低。

CockroachDB (蟑螂DB/小强DB)

CockroachDB(中文名蟑螂DB,所以又可以称为小强DB),是构建于事务处理及强一致性KV存储上的分布式SQL数据库,支持水平扩展、自动容错处理、强一致性事务,并且提供SQL接口用于数据处理,是Google Spanner/F1的开源实现。 CockroachDB适用于应用对数据要求精确、可靠、完全正确的场景,支持自动复制、均匀分布、基于极小配置的数据恢复,可用于分布式的、可复制的联机事务处理(OLTP),多数据中心的部署,私有云的基础构建,它不适用于读少写多的场景,可以用内存数据库来代替,也不适用于复杂的join查询,重量级的数据分析及联机分析处理(OLAP)。

Logus:另一种简单、优雅、高效打Log的方式

起源:

最近项目中有使用Uber的zap(Go语言生态中一种高效打印Log的实用库,久经考验)打印log,用的顺手,于是借鉴其中的设计思想,在Android环境下封装Log类提供相似功能。

设计思想:

分离消息与数据域,避免字符串拼接和效率低的字符串格式化

  • 把log信息分两段:消息和数据域;消息是必须的, 数据域是个数可变的键-值对
  • 消息仅仅是String,不带任何格式化或字符串拼接
  • 数据域是以key-value的形式成对作为参数传给打印函数,忽略最后一个不成对参数
  • 内部实现是使用StringBuilder组合最终要打印的信息,避免过多的字符串拼接导致log打印频繁时给gc过多压力
  • StackTrace信息是可以设置打印或不打印

用例:

// file: MainActivity.java
@Override
protected void onResume() {
    super.onResume();
    Logus.d("just a message");
    Logus.e("a field message", "a", 1);
    Logus.w("3 fields but see 2", "a", 1, "b", true, "c");
    Logus.V("Main", "with prefix just a message");
    Logus.E("Main", "with prefix 2 fields", "a", 10, "b", false);
    Logus.E("Main", "with prefix 3 fields but log 2", "a", 10, "b", true, "c");
    Logus.setStackTrace(false);
    Logus.E("Main", "no stack trace with prefix");
}

// 输出:
04-19 22:12:56.209 3256-3256/net.gility.note  D/Logus: MainActivity.java(425)#onResume > just a message
04-19 22:12:56.210 3256-3256/net.gility.note  E/Logus: MainActivity.java(426)#onResume > a field message { a=1; }
04-19 22:12:56.210 3256-3256/net.gility.note  W/Logus: MainActivity.java(427)#onResume > 3 fields but see 2 { a=1; b=true; }
04-19 22:12:56.211 3256-3256/net.gility.note  V/Logus: MainActivity.java(428)#onResume Main> with prefix just a message
04-19 22:12:56.212 3256-3256/net.gility.note  E/Logus: MainActivity.java(429)#onResume Main> with prefix 2 fields { a=10; b=false; }
04-19 22:12:56.213 3256-3256/net.gility.note  E/Logus: MainActivity.java(430)#onResume Main> with prefix 3 fields but log 2 { a=10; b=true; }
04-19 22:12:56.213 3256-3256/net.gility.note  D/Logus: > no stack trace no prefix
04-19 22:12:56.213 3256-3256/net.gility.note  E/Logus: Main> no stack trace with prefix

rsync: 基本命令和用法

1 说在前面的话

rsync官方网站: https://www.samba.org/ftp/rsync/rsync.html

rsync是可以实现增量备份的工具。配合任务计划,rsync能实现定时或间隔同步,配合inotify或sersync,可以实现触发式的实时同步。

rsync可以实现scp的远程拷贝(rsync不支持远程到远程的拷贝,但scp支持)、cp的本地拷贝、rm删除和"ls -l"显示文件列表等功能。但需要注意的是,rsync的最终目的或者说其原始目的是实现两端主机的文件同步,因此实现的scp/cp/rm等功能仅仅只是同步的辅助手段,且rsync实现这些功能的方式和这些命令是不一样的。事实上,rsync有一套自己的算法,其算法原理以及rsync对算法实现的机制可能比想象中要复杂一些。平时使用rsync实现简单的备份、同步等功能足以,没有多大必要去深究这些原理性的内容。但是想要看懂rsync命令的man文档、使用"-vvvv"分析rsync执行过程,以及实现rsync更强大更完整的功能,没有这些理论知识的支持是绝对不可能实现的。本篇文章将简单介绍rsync的使用方法和它常用的功能。在本篇文章之后的下几篇文章中,将介绍inotify+rsync和sersync,再之后将详细解释rsync相关的原理,其中包括官方技术报告的翻译(即算法原理)、rsync同步的整个过程(也是官方推荐文章的翻译),然后专门使用一篇文章通过示例来详细解释rsync算法原理,最后给出rsync的man文档翻译。希望各位朋友能藉此深入rsync。

回归正题,以下是rsync相关基础内容。

rsync: 中文手册

rsync(1)

名称
rsync - 一个快速、多功能的远程(和本地)文件拷贝工具

摘要
Local: rsync [OPTION…] SRC… [DEST]

   Access via remote shell:
     Pull: rsync [OPTION...] [USER@]HOST:SRC... [DEST]
     Push: rsync [OPTION...] SRC... [USER@]HOST:DEST

   Access via rsync daemon:
     Pull: rsync [OPTION...] [USER@]HOST::SRC... [DEST]
           rsync [OPTION...] rsync://[USER@]HOST[:PORT]/SRC... [DEST]
     Push: rsync [OPTION...] SRC... [USER@]HOST::DEST
           rsync [OPTION...] SRC... rsync://[USER@]HOST[:PORT]/DEST


   当仅有一个SRC或DEST参数时将列出源文件列表而不是复制文件。

描述