GoLang实现跨平台的一些技巧02

以新建文件为例,对比一下几个常见平台的区别。

继续看下Linux平台的代码:

// os/file.go

// 新建文件
func Create(name string) (*File, error) {
	// 跳转到下面的OpenFile
	return OpenFile(name, O_RDWR|O_CREATE|O_TRUNC, 0666)
}

// OpenFile在这里还是平台无关的代码
func OpenFile(name string, flag int, perm FileMode) (*File, error) {
	testlog.Open(name)
	// 从openFileNolog开始,不同平台代码会有不同
	f, err := openFileNolog(name, flag, perm)
	if err != nil {
		return nil, err
	}
	f.appendMode = flag&O_APPEND != 0

	return f, nil
}
// os/file_unix.go

// openFileNolog的unix实现
func openFileNolog(name string, flag int, perm FileMode) (*File, error) {
	setSticky := false
	if !supportsCreateWithStickyBit && flag&O_CREATE != 0 && perm&ModeSticky != 0 {
		if _, err := Stat(name); IsNotExist(err) {
			setSticky = true
		}
	}

	var r int
	var s poll.SysFile
	for {
		var e error
		//跳转到open
		r, s, e = open(name, flag|syscall.O_CLOEXEC, syscallMode(perm))
		if e == nil {
			break
		}

		// We have to check EINTR here, per issues 11180 and 39237.
		if e == syscall.EINTR {
			continue
		}

		return nil, &PathError{Op: "open", Path: name, Err: e}
	}

	// open(2) itself won't handle the sticky bit on *BSD and Solaris
	if setSticky {
		setStickyBit(name)
	}

	// There's a race here with fork/exec, which we are
	// content to live with. See ../syscall/exec_unix.go.
	if !supportsCloseOnExec {
		syscall.CloseOnExec(r)
	}

	kind := kindOpenFile
	if unix.HasNonblockFlag(flag) {
		kind = kindNonBlock
	}

	// 封装为File结构
	f := newFile(r, name, kind)
	f.pfd.SysFile = s
	return f, nil
}
// os/file_open_unix.go

func open(path string, flag int, perm uint32) (int, poll.SysFile, error) {
	// 跳转到syscall.Open
	fd, err := syscall.Open(path, flag, perm)
	return fd, poll.SysFile{}, err
}
// syscall/syscall_linux.go

func Open(path string, mode int, perm uint32) (fd int, err error) {
	// 跳转到openat
	return openat(AT_FDCWD, path, mode|O_LARGEFILE, perm)
}

//sys	openat(dirfd int, path string, flags int, mode uint32) (fd int, err error)

// syscall/zsyscall_linux_amd64.go

func openat(dirfd int, path string, flags int, mode uint32) (fd int, err error) {
	var _p0 *byte
	_p0, err = BytePtrFromString(path)
	if err != nil {
		return
	}
	// 跳转到Syscall6
	r0, _, e1 := Syscall6(SYS_OPENAT, uintptr(dirfd), uintptr(unsafe.Pointer(_p0)), uintptr(flags), uintptr(mode), 0, 0)
	fd = int(r0)
	if e1 != 0 {
		err = errnoErr(e1)
	}
	return
}
// syscall/syscall_linux.go

func Syscall6(trap, a1, a2, a3, a4, a5, a6 uintptr) (r1, r2 uintptr, err Errno) {
	runtime_entersyscall()
	// 跳转到RawSyscall6
	r1, r2, err = RawSyscall6(trap, a1, a2, a3, a4, a5, a6)
	runtime_exitsyscall()
	return
}

// N.B. RawSyscall6 is provided via linkname by runtime/internal/syscall.
//
// Errno is uintptr and thus compatible with the runtime/internal/syscall
// definition.
func RawSyscall6(trap, a1, a2, a3, a4, a5, a6 uintptr) (r1, r2 uintptr, err Errno)

// syscall/zsysnum_linux_amd64.go
	SYS_OPENAT                 = 257

// RawSyscall6是通过汇编实现的,传入SYS_OPENAT,最终调用openat函数
// openat函数是libc标准库中的函数,C语言定义为
int openat(int dirfd, const char *pathname, int flags, mode_t mode);
// runtime/internal/syscall/asm_linux_amd64.s

// Syscall6 的实现在这里
// func Syscall6(num, a1, a2, a3, a4, a5, a6 uintptr) (r1, r2, errno uintptr)
//
// We need to convert to the syscall ABI.
//
// arg | ABIInternal | Syscall
// ---------------------------
// num | AX          | AX
// a1  | BX          | DI
// a2  | CX          | SI
// a3  | DI          | DX
// a4  | SI          | R10
// a5  | R8          | R8
// a6  | R9          | R9
//
// r1  | AX          | AX
// r2  | BX          | DX
// err | CX          | part of AX
//
// Note that this differs from "standard" ABI convention, which would pass 4th
// arg in CX, not R10.
TEXT ·Syscall6<ABIInternal>(SB),NOSPLIT,$0
	// a6 already in R9.
	// a5 already in R8.
	MOVQ	SI, R10 // a4
	MOVQ	DI, DX  // a3
	MOVQ	CX, SI  // a2
	MOVQ	BX, DI  // a1
	// num already in AX.
	SYSCALL
	CMPQ	AX, $0xfffffffffffff001
	JLS	ok
	NEGQ	AX
	MOVQ	AX, CX  // errno
	MOVQ	$-1, AX // r1
	MOVQ	$0, BX  // r2
	RET
ok:
	// r1 already in AX.
	MOVQ	DX, BX // r2
	MOVQ	$0, CX // errno
	RET

// 然后回到openFileNolog中
// 在openFileNolog中,继续调用newFile,整体封装为File结构,原路返回
func newFile(fd int, name string, kind newFileKind) *File {
	f := &File{&file{
		pfd: poll.FD{
			Sysfd:         fd,
			IsStream:      true,
			ZeroReadIsEOF: true,
		},
		name:        name,
		stdoutOrErr: fd == 1 || fd == 2,
	}}

	pollable := kind == kindOpenFile || kind == kindPipe || kind == kindNonBlock

	// If the caller passed a non-blocking filedes (kindNonBlock),
	// we assume they know what they are doing so we allow it to be
	// used with kqueue.
	if kind == kindOpenFile {
		switch runtime.GOOS {
		case "darwin", "ios", "dragonfly", "freebsd", "netbsd", "openbsd":
			var st syscall.Stat_t
			err := ignoringEINTR(func() error {
				return syscall.Fstat(fd, &st)
			})
			typ := st.Mode & syscall.S_IFMT
			// Don't try to use kqueue with regular files on *BSDs.
			// On FreeBSD a regular file is always
			// reported as ready for writing.
			// On Dragonfly, NetBSD and OpenBSD the fd is signaled
			// only once as ready (both read and write).
			// Issue 19093.
			// Also don't add directories to the netpoller.
			if err == nil && (typ == syscall.S_IFREG || typ == syscall.S_IFDIR) {
				pollable = false
			}

			// In addition to the behavior described above for regular files,
			// on Darwin, kqueue does not work properly with fifos:
			// closing the last writer does not cause a kqueue event
			// for any readers. See issue #24164.
			if (runtime.GOOS == "darwin" || runtime.GOOS == "ios") && typ == syscall.S_IFIFO {
				pollable = false
			}
		}
	}

	clearNonBlock := false
	if pollable {
		if kind == kindNonBlock {
			// The descriptor is already in non-blocking mode.
			// We only set f.nonblock if we put the file into
			// non-blocking mode.
		} else if err := syscall.SetNonblock(fd, true); err == nil {
			f.nonblock = true
			clearNonBlock = true
		} else {
			pollable = false
		}
	}

	// An error here indicates a failure to register
	// with the netpoll system. That can happen for
	// a file descriptor that is not supported by
	// epoll/kqueue; for example, disk files on
	// Linux systems. We assume that any real error
	// will show up in later I/O.
	// We do restore the blocking behavior if it was set by us.
	if pollErr := f.pfd.Init("file", pollable); pollErr != nil && clearNonBlock {
		if err := syscall.SetNonblock(fd, false); err == nil {
			f.nonblock = false
		}
	}

	runtime.SetFinalizer(f.file, (*file).close)
	return f
}

GoLang实现跨平台的一些技巧01

最近在读GoLang的源码,源码中有一些跨平台的操作,Go处理的很有意思,在这整理一下。

以新建文件为例,对比一下几个常见平台的区别。

首先看下Windows平台的代码:

// os/file.go

// 新建文件
func Create(name string) (*File, error) {
	// 跳转到下面的OpenFile
	return OpenFile(name, O_RDWR|O_CREATE|O_TRUNC, 0666)
}

// OpenFile在这里还是平台无关的代码
func OpenFile(name string, flag int, perm FileMode) (*File, error) {
	testlog.Open(name)
	// 从openFileNolog开始,不同平台代码会有不同
	f, err := openFileNolog(name, flag, perm)
	if err != nil {
		return nil, err
	}
	f.appendMode = flag&O_APPEND != 0

	return f, nil
}
// os/file_windows.go

// openFileNolog的windows实现
func openFileNolog(name string, flag int, perm FileMode) (*File, error) {
	if name == "" {
		return nil, &PathError{Op: "open", Path: name, Err: syscall.ENOENT}
	}
	path := fixLongPath(name)
	// 跳转到了syscall.Open
	r, e := syscall.Open(path, flag|syscall.O_CLOEXEC, syscallMode(perm))
	if e != nil {
		// We should return EISDIR when we are trying to open a directory with write access.
		if e == syscall.ERROR_ACCESS_DENIED && (flag&O_WRONLY != 0 || flag&O_RDWR != 0) {
			pathp, e1 := syscall.UTF16PtrFromString(path)
			if e1 == nil {
				var fa syscall.Win32FileAttributeData
				e1 = syscall.GetFileAttributesEx(pathp, syscall.GetFileExInfoStandard, (*byte)(unsafe.Pointer(&fa)))
				if e1 == nil && fa.FileAttributes&syscall.FILE_ATTRIBUTE_DIRECTORY != 0 {
					e = syscall.EISDIR
				}
			}
		}
		return nil, &PathError{Op: "open", Path: name, Err: e}
	}

	// 封装为File结构
	f, e := newFile(r, name, "file"), nil
	if e != nil {
		return nil, &PathError{Op: "open", Path: name, Err: e}
	}
	return f, nil
}
// syscall/syscall_windows.go

func Open(path string, mode int, perm uint32) (fd Handle, err error) {
	if len(path) == 0 {
		return InvalidHandle, ERROR_FILE_NOT_FOUND
	}
	pathp, err := UTF16PtrFromString(path)
	if err != nil {
		return InvalidHandle, err
	}
	var access uint32
	switch mode & (O_RDONLY | O_WRONLY | O_RDWR) {
	case O_RDONLY:
		access = GENERIC_READ
	case O_WRONLY:
		access = GENERIC_WRITE
	case O_RDWR:
		access = GENERIC_READ | GENERIC_WRITE
	}
	if mode&O_CREAT != 0 {
		access |= GENERIC_WRITE
	}
	if mode&O_APPEND != 0 {
		access &^= GENERIC_WRITE
		access |= FILE_APPEND_DATA
	}
	sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE)
	var sa *SecurityAttributes
	if mode&O_CLOEXEC == 0 {
		sa = makeInheritSa()
	}
	var createmode uint32
	switch {
	case mode&(O_CREAT|O_EXCL) == (O_CREAT | O_EXCL):
		createmode = CREATE_NEW
	case mode&(O_CREAT|O_TRUNC) == (O_CREAT | O_TRUNC):
		createmode = CREATE_ALWAYS
	case mode&O_CREAT == O_CREAT:
		createmode = OPEN_ALWAYS
	case mode&O_TRUNC == O_TRUNC:
		createmode = TRUNCATE_EXISTING
	default:
		createmode = OPEN_EXISTING
	}
	var attrs uint32 = FILE_ATTRIBUTE_NORMAL
	if perm&S_IWRITE == 0 {
		attrs = FILE_ATTRIBUTE_READONLY
		if createmode == CREATE_ALWAYS {
			// We have been asked to create a read-only file.
			// If the file already exists, the semantics of
			// the Unix open system call is to preserve the
			// existing permissions. If we pass CREATE_ALWAYS
			// and FILE_ATTRIBUTE_READONLY to CreateFile,
			// and the file already exists, CreateFile will
			// change the file permissions.
			// Avoid that to preserve the Unix semantics.
			h, e := CreateFile(pathp, access, sharemode, sa, TRUNCATE_EXISTING, FILE_ATTRIBUTE_NORMAL, 0)
			switch e {
			case ERROR_FILE_NOT_FOUND, _ERROR_BAD_NETPATH, ERROR_PATH_NOT_FOUND:
				// File does not exist. These are the same
				// errors as Errno.Is checks for ErrNotExist.
				// Carry on to create the file.
			default:
				// Success or some different error.
				return h, e
			}
		}
	}
	if createmode == OPEN_EXISTING && access == GENERIC_READ {
		// Necessary for opening directory handles.
		attrs |= FILE_FLAG_BACKUP_SEMANTICS
	}
	if mode&O_SYNC != 0 {
		const _FILE_FLAG_WRITE_THROUGH = 0x80000000
		attrs |= _FILE_FLAG_WRITE_THROUGH
	}

	// 跳转CreateFile
	return CreateFile(pathp, access, sharemode, sa, createmode, attrs, 0)
}


func CreateFile(name *uint16, access uint32, mode uint32, sa *SecurityAttributes, createmode uint32, attrs uint32, templatefile int32) (handle Handle, err error) {
	// 跳转Syscall9
	r0, _, e1 := Syscall9(procCreateFileW.Addr(), 7, uintptr(unsafe.Pointer(name)), uintptr(access), uintptr(mode), uintptr(unsafe.Pointer(sa)), uintptr(createmode), uintptr(attrs), uintptr(templatefile), 0, 0)
	handle = Handle(r0)
	if handle == InvalidHandle {
		err = errnoErr(e1)
	}
	return
}
// syscall/dll_windows.go
// 封装了Syscall9
func Syscall9(trap, nargs, a1, a2, a3, a4, a5, a6, a7, a8, a9 uintptr) (r1, r2 uintptr, err Errno)

// syscall/zsyscall_windows.go
// Syscall9中传入的API名为procCreateFileW 
procCreateFileW                        = modkernel32.NewProc("CreateFileW")

// 实际上最终调用了windows API CreateFileW,下面是CPP版本的API定义
// 到这里,也可以看到,通过Syscall的定义,比较巧妙的做了一定程度上的解耦
HANDLE CreateFileW(
  [in]           LPCWSTR               lpFileName,
  [in]           DWORD                 dwDesiredAccess,
  [in]           DWORD                 dwShareMode,
  [in, optional] LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  [in]           DWORD                 dwCreationDisposition,
  [in]           DWORD                 dwFlagsAndAttributes,
  [in, optional] HANDLE                hTemplateFile
);
// runtime/syscall_windows.go

// Syscall9是在这里实现的
//go:linkname syscall_Syscall9 syscall.Syscall9
//go:nosplit
func syscall_Syscall9(fn, nargs, a1, a2, a3, a4, a5, a6, a7, a8, a9 uintptr) (r1, r2, err uintptr) {
	return syscall_SyscallN(fn, a1, a2, a3, a4, a5, a6, a7, a8, a9)
}

//go:linkname syscall_SyscallN syscall.SyscallN
//go:nosplit
func syscall_SyscallN(trap uintptr, args ...uintptr) (r1, r2, err uintptr) {
	nargs := len(args)

	// asmstdcall expects it can access the first 4 arguments
	// to load them into registers.
	var tmp [4]uintptr
	switch {
	case nargs < 4:
		copy(tmp[:], args)
		args = tmp[:]
	case nargs > maxArgs:
		panic("runtime: SyscallN has too many arguments")
	}

	lockOSThread()
	defer unlockOSThread()
	c := &getg().m.syscall
	c.fn = trap
	c.n = uintptr(nargs)
	c.args = uintptr(noescape(unsafe.Pointer(&args[0])))
	cgocall(asmstdcallAddr, unsafe.Pointer(c))
	return c.r1, c.r2, c.err
}

// 最后,通过cgocall,将go的调用,转换为c的调用
// 然后回到openFileNolog中
// 在openFileNolog中,继续调用newFile,整体封装为File结构,原路返回
func newFile(h syscall.Handle, name string, kind string) *File {
	if kind == "file" {
		var m uint32
		if syscall.GetConsoleMode(h, &m) == nil {
			kind = "console"
		}
		if t, err := syscall.GetFileType(h); err == nil && t == syscall.FILE_TYPE_PIPE {
			kind = "pipe"
		}
	}

	f := &File{&file{
		pfd: poll.FD{
			Sysfd:         h,
			IsStream:      true,
			ZeroReadIsEOF: true,
		},
		name: name,
	}}
	runtime.SetFinalizer(f.file, (*file).close)

	// Ignore initialization errors.
	// Assume any problems will show up in later I/O.
	f.pfd.Init(kind, false)

	return f
}

分布式一致性算法06:Gossip

Gossip是一个最终一致性协议,适用于大规模的、弱一致性的、去中心化的场景。

为了达到最终一致性,Gossip实际上提供了三种同步方式:Direct Mail(直接邮寄)、Rumor Mongering(谣言传播)及 Anti-Entropy(反熵)。看起来都是新技术名词,但分开来看,却都十分简单。

1、Direct Mail(直接邮寄,增量)
通俗解释就是,当一个节点收到客户端的新信息后,就把这个新信息传递给系统内的每个节点。
Direct Mail功能实现简单、效率也很高。

但在一个开放性的大规模非中心化网络中,经常会出现节点的变化(增加、掉线、宕机),这种场景下,仅靠Direct Mail,是不可能实现最终一致性的。
比如,节点X宕机了1一小时,然后启动。这一小时中的数据就丢失了。虽然在技术上,我们可以将信息做一些缓存,但在一个开放网络里,管理每个节点是否接收并处理好自己发送的全部消息,这本身就是个技术难题,而且效率将会及其低下。

2、Anti-Entropy(反熵,全量)
通俗解释就是,一个节点,定期会选择一些节点,对比数据的差异,并相互修复缺失的数据。
同步方式,可以是推送、拉取、连推带拉。
Anti-Entropy会比较整个数据库的异同,是达成最终一致性的最后手段。

Anti-Entropy消息以固定的概率传播全量的数据。
所有节点只有两种状态:Suspective(病原)、Infective(感染),也被称作simple epidemics(SI model)。
S节点会把所有的数据都跟I节点共享,以便消除节点之间数据的任何不一致,它可以保证最终、完全的一致。

但是,在一个开放性的大规模非中心化网络中,定期同步全量数据,将会带来巨大的资源消耗。
所以这个操作的频率,必须足够低,否则整个网络就不用做其他事情了。
注:在实际工程落地中,为了加快数据同步效率,并不一定会“随机”选择同步节点,而是会想办法,用一定的顺序,尽快让全部节点完成同步。

聪明的你一定会发现,通过Direct Mail和Anti-Entropy,已经可以实现最终一致性的效果了。
但Direct Mail无法保证成功,Anti-Entropy无法保证频率,我们需要寻找额外的同步方案,在消耗尽量少资源的前提下,让整个网络的的可用性大幅提升。

3、Rumor Mongering(谣言传播,增量)
通俗解释就是,当一个节点收到新消息后,随机挑选N个节点,把新消息推送给这些节点。这N的节点在收到消息后,又会分别随机选择N个节点,推送新消息。
同步方式,同样可以是推送、拉取、连推带拉。

Rumor Mongering消息以固定的概率传播增量数据。
所有节点有三种状态:Suspective(病原)、Infective(感染)、Removed(愈除)。也被称作complex epidemics(SIR model)。
S节点只会把追加消息发送给随机选择的I节点。而这个消息在某个时间点之后会被标记为Removed,并且不再被传播。
根据六度分隔理论,经过几轮随机推送,可以基本确保每个节点都收到了新消息。但部分特殊节点仍有可能并未收到所有的追加消息。
所以,通过Direct Mail和Rumor Mongering并无法保证达到最终一致性。

聪明的你一定会发现,这一个信息,会被多次重复推送,一个节点也会重复接收。这其实是一个实现复杂度和性能之间的一个均衡。
和协议的名字相似,风言风语,口口相传,很快全村就都知道了。

4、新节点加入怎么处理
当一个节点加入网络后,会先使用Anti-Entropy的拉取方式,获取一个相对比较新的数据库。
然后就可以通过Direct Mail、Rumor Mongering获取新数据啦。
最后,还有Anti-Entropy,定期全量对比更新数据,这样新节点加入后,网络很快就能达到一致性了。

可见,Gossip协议,原理很简单,实现也并不复杂。虽然有一定程度的通讯浪费,但对于开放性的大规模非中心化网络中,Gossip协议很好的平衡了可用性、性能、工程复杂度之间的关系,实际中也获得了不少项目的青睐。

分布式一致性算法05:NWR

分布式一致性算法05 NWR协议

一、基本概念
NWR模型是一种强一致性算法,它巧妙的利用了N(备份数)、W(写入成功数)、R(读取成功数)之间的关系(W+R>N),从而达到一致性的要求。

其中:
N(备份数):系统中备份的总数。
W(写入成功数):执行写操作时,需要写入成功的最小备份数量。
R(读取成功数):执行读操作时,需要查询成功的最小备份数量。

为了保证一致性,必须满足以下条件:
W+R>N
这个不等式确保了在执行读操作时,至少有一个最新的备份被读取到,从而避免了读到过时的数据。

二、相关角色
NWR协议中,所有的节点是一样的。

三、算法流程
1、客户端请求写入
各节点收到消息,写入成功后,返回写入成功
当客户端收到W以上个写入成功后,认为写入成功
2、客户端读取请求
个节点收到读取消息,返回结果
当客户端收到R个以上的结果后,直接使用最新版本的数据即可。

由于W+R>N,所以客户端至少可以读取到一份最新的数据,不会读取到历史版本。

四、举例说明
假设我们有一个分布式系统,其中有5个节点,即N=5。
要求确保写操作在至少3个节点上成功(W=3),并且读操作至少查询3个节点(R=3)。

1、写操作
客户端向系统发送一个写请求,比如更新某个键值对。

2、写操作的传播
写请求被发送到所有5个备份节点,等待至少3个节点确认写操作成功。

3、写操作的确认
假设有3个节点成功更新了数据,满足了W=3的要求,写操作被认为是成功的。

4、读操作
客户端发送一个读请求,希望获取最新的键值对数据。

5、读操作的数据收集
系统从5个备份节点中的任意3个节点获取数据,由于W+R>N(3+3>5),至少有一个节点上的数据是最新的。

6、结果的确认
客户端收到来自3个节点的响应,可能会发现不同节点的数据版本不同。
客户端选择版本号最高的数据使用即可。

五、NWR的优点
1、实现简单
2、在NWR体系下,无需等待所有节点都写入成功,即可判定数据更新成功,而且保证可以读取到最新数据,提升了系统的吞吐量,同时系统的可用性也有较大提升。
3、即使部分节点宕机,只要能保证W+R>N,系统还是处于可运行状态,比如
N=5,W=3,R=3
即使宕掉2个节点,仍然可以保证运行,只不过系统退化为了强C系统。

六、NWR突破了CAP的限制吗?
并没有哦,其实我们挑战一下NWR的设置就可以看懂了(先不考虑P,我们讨论一下CA)
当W=N、R=1的时候,其实就是写入时,牺牲了A,保证了C(节点都一致)
当W=1、R=N,其实就是写入时,保证了A,牺牲了C(节点都不一致)

分布式一致性算法04:ZAB协议

分布式一致性算法04 ZAB协议

一、基本概念
ZAB(Zookeeper Atomic Broadcast)协议是为Apache Zookeeper框架设计的一致性协议。
与Paxos仅能保证事务的一致性不同,ZAB可以同时保证事务的顺序性和一致性。

二、ZAB算法涉及三种角色和四种状态
三种角色:
1、领导者(Leader): 在同一时间,集群只会有一个领导者。所有的写请求都必须在领导者节点执行。
2、跟随者(Follower):集群可以有多个跟随者,它们会响应领导者的心跳,并参与领导者选举和提案提交的投票。跟随者可以直接处理来自客户端的读请求,但会将写请求转发给领导者处理。
3、观察者(Observer):与跟随者类似,但不参与竞选和投票权。

节点有四种状态:
LOOKING:选举状态,该状态下的节点认为当前集群中没有领导者,会发起领导者选举。
LEADING :领导者状态,意味着当前节点是领导者。
FOLLOWING :跟随者状态,意味着当前节点是跟随者。
OBSERVING: 观察者状态,意味着当前节点是观察者。

三、关键概念
1、Epoch(纪元)
定义:Epoch是ZXID的高32位,表示领导者的任期编号。每次新的领导者被选举出来时,Epoch都会增加。
作用:
标识领导者的任期。不同的Epoch代表不同的领导者任期,确保了领导者的唯一性。
当发生分区或领导者故障时,新的领导者会具有更高的Epoch,从而确保了新的领导者具有最新的状态。

2、ZXID(事务ID)
定义:ZXID是一个64位的数字,用于唯一标识Zookeeper中的每个事务。
组成:ZXID的高32位表示Epoch,低32位表示事务计数器(XID)。
作用:
确保事务的全局顺序性。每个事务都有一个唯一的ZXID,保证了事务在所有服务器上的处理顺序一致。
通过比较ZXID,服务器可以确定事务的先后顺序,以及是否已经处理过某个事务。

四、ZAB选举流程
1、初始化:
集群中的每个服务器(Server)启动时,都处于“Looking”状态,即寻找Leader状态。

2、投票:
每个处于“Looking”状态的服务器都会发送投票(Vote)给其他服务器,尝试将自己选举为Leader。
投票格式大概为:
(新Leader节点的ID, 新Epoch编号, 当前最新的ZXID,投票节点的ID)

3、收集选票:
收到各节点的选票后,各节点会根据以下规则,判定如何投票:
优先检查任期编号Epoch,任期编号大的节点作为领导者;
如果任期编号Epoch相同,比较事务标识符ZXID的最大值,值大的节点作为领导者;
如果事务标识符的最大值相同,比较节点ID,节点ID大的节点作为领导者;
通过这样的规则,首先保证了数据最新的节点,获取更高的票数。

4、确定Leader
如果没有任何节点获取了过半选票,则要开始下一轮选举,回到步骤2,但此时不再会投票给自己,而是会投票给上一轮最合适的节点。
如果某个服务器获得了超过半数的投票,它就认为自己被选举为新的Leader。

5、同步:
新Leader会与集群中的Follower进行数据同步,确保所有Follower的数据与Leader一致。
数据同步完成,Leader就可以接收客户端的事务请求了。

五、ZAB选举示例
假设我们有一个Zookeeper集群,包含5个节点(P1~P5),所有节点都处于“Looking”状态。
Epoch=2;XID=5;ZXID=(2,5)
投票信息格式为:
(新Leader的ID, 新Leader的Epoch编号, 新Leader的最新的ZXID,选举轮次,投票节点的ID)

1、初始化
P1~P5开始寻找Leader,并发送投票请求,并投票给自己。

2、投票
P1:(新Leader=P1, 新Leader的Epoch=2, 新Leader的最新的ZXID=(2,5),选举轮次=1,投票节点=P1)
P2:(新Leader=P2, 新Leader的Epoch=2, 新Leader的最新的ZXID=(2,5),选举轮次=1,投票节点=P2)
P3:(新Leader=P3, 新Leader的Epoch=2, 新Leader的最新的ZXID=(2,3),选举轮次=1,投票节点=P3)
P4:(新Leader=P4, 新Leader的Epoch=2, 新Leader的最新的ZXID=(2,2),选举轮次=1,投票节点=P4)
P5:(新Leader=P5, 新Leader的Epoch=1, 新Leader的最新的ZXID=(1,1),选举轮次=1,投票节点=P5)

3、收集选票
对于同一轮的选票,节点自行对比判定选举结果:
P1:新Leader=P2,因为P2节点ID更大
P2:新Leader=P2,不变
P3:新Leader=P2,因为P2 ZXID更大
P4:新Leader=P2,因为P2 ZXID更大
P5:新Leader=P2,因为P2 Epoch更大
但如果一个节点收到了更小选举轮次(logicalclock)的投票,该投票会被忽略。

4、再次投票,这样P2会获得全部5票

5、确定Leader
P2认为被选举为Leader。其余节点,会主动与P2交换最大的ZXID,如果P2的更新则承认P2的领导地位,否则重新发起选举。
当过半节点承认P2的领导地位时,P2正式成为Leader。
同时P2会将Epoch+1,此时:
Epoch=3;ZXID=(3,0)

6、同步
P2根据之前各节点反馈的最大ZXID,开始与其他节点进行数据同步,强制要求所有Follower的数据与自己的数据一致。
数据同步完成后,P2告知全部Follower数据同步完毕,P2开始接收提案,各节点开始同步P2的提案。

六、ZAB同步算法的工作流程
延续上面的例子,Zookeeper集群,包含5个节点(P1~P5),P2是Leader
Epoch=3;XID=0;ZXID=(3,0)

1、客户端请求:
客户端向P3发送写请求,P3会将写请求转交给Leader P2。

2、事务提案:
Leader接收到请求后,会生成一个事务提案Proposal,分配一个全局唯一的ZXID,并进行持久化。

3、广播提案:
Leader将事务提案发送给所有Follower。

4、Follower投票:
Follower接收到提案后,会将Proposal写入本地日志,并根据自身的数据状态进行投票(必须按ZXID顺序提交),并将投票结果发送回Leader。

5、Leader决策
当Leader收到超过半数Follower的同意投票后,提交事务。同时将通知所有Follower更新状态。
如果提案被拒绝,事务将被回滚。

6、客户端响应
P3收到Leader事务提交的消息,P3会向客户端返回操作结果,客户端根据结果进行相应的处理。

七、ZAB协议的关键点:
1、顺序一致性:ZAB协议通过全局唯一的ZXID,保证了客户端请求的顺序性。
2、可靠性:即使在部分节点宕机的情况下(投票数可以过半),ZAB协议也能够保证系统的可靠性和数据的一致性。
3、防止分区:当新Leader选举成功后,如果旧Leader恢复过来,由于新Leader有更高的Epoch,旧Leader的请求不再会被接受;一个节点,如果与Leader失联,则是无法处理读写请求的;

可以看出,ZAB算法与RAFT算法整体的考虑方向是一致的,就是先选择一个Leader,通过Leader控制事务提交的顺序。
但就具体的实现而言,RAFT的实现更简单可以实现强一致性,ZAB的实现更复杂一些可以实现最终一致性。

分布式一致性算法03:RAFT

分布式一致性算法03 RAFT协议

一、基本概念
Raft算法首选会选举一位领导者(Leader),所有的写请求都先提交给Leader,Leader通过日志复制(Log Replication)来保持集群中所有节点的状态一致。

在这个过程中有一些限制:
1、Leader只能有一个,Leader会通过心跳包告知其他节点,“我是Leader,我还活着,你们别想选举”
2、Leader和Follower之间通过日志同步的方式达成一致;在一条日志中,包含了索引编号、指令、Leader任期等信息
3、日志记录了所有的事务操作,必须在所有节点上顺序一致(索引编号是递增的)
4、Raft算法通过任期编号和选举超时机制来避免分裂脑现象,确保在任期内只有一个Leader

二、RAFT算法通常涉及三种角色
领导者(Leader):负责处理所有客户端请求,将日志条目(Log Entries)复制到其他节点。
跟随者(Follower):接收领导者的日志条目并保持与领导者的心跳连接。
候选者(Candidate):当跟随者在一定时间内没有收到领导者的心跳时,它们会变成候选者并尝试成为新的领导者。
在实际情况中,一个节点通常只会承担一个角色,但这个角色通过选举机制是可以相互转换的。

三、RAFT Leader初始过程
1、当系统初始化时,或者Leader状态异常无法正常发送心跳包后,会开启选举过程。
2、此时,每个节点都是Follower,每个Follower都持有一个时间随机的选举计时器。
3、当一个Follower的选举计时器超时后,该Follower会判定Leader不可用,于是它自增任期号,并转换为Candidate。
4、Candidate首选会给自己投票,并向其他节点发送 RequestVote RPCs 请求投票,该请求中包含新任期号以及日志信息。
5、其余节点收到请求后,会检查请求中的任期号和自己的日志信息。如果受到的任期号更大,它们会投票给该Candidate。
6、如果一个Candidate从集群中大多数节点那里收到投票,它就赢得了选举,成为新的Leader。
7、新的Leader会立即向所有节点发送心跳信息,以通知它们自己的存在,并防止它们变成Candidate。

四、选举过程举例
假设一个5节点组成的Raft集群P1~P5,其中P1是Leader,其余为Follower,此时任期为Term1。此时P1故障,无法发送心跳包。

1、P2~P4节点都为Follower状态,每个节点都会初始化一个随机的选举计时器。
计时器分别为:P2 100ms,P3 200ms,P4 300ms,P5 400ms

2、由于一直收不到心跳包,P2的选举计时器会首先超时。
此时P2会在任期号Term1上增加,生成任期号Term2,并转换为 Candidate 状态。

3、P2给自己投票,并向其他全部节点发送 RequestVote RPCs 请求投票,并带上任期号Term2

4、P3~P5收到投票后,对比Term2和自己日志中的任期号
如果日志任期号更达,则拒绝投票
在本例中,Term2任期号更大,P3~P5就都会投票给P2

5、P2收到P3~P5的投票,加上自己的一票,超过半数,选举成功,P2成为新的Leader

6、P2会立即向所有节点发送心跳信息,其他竞选失败的Candidate,退回为Follower状态,开始跟随Leader的日志。
所有Follower会重置选举计时器,等待再次成为Candidate,并发起选举。

7、在日志复制之前,P2需要确定自己的日志与Follower的日志是否一致。它会发送AppendEntries RPC请求给Follower,并在请求中包含自己日志的最后一个日志Entry(索引和命令)和任期(PrevLogEntry和PrevLogTerm)。
如果Follower的日志与Leader匹配,则可以开始日志同步。
如果Follower的日志与Leader不匹配,它会发送一个失败的响应。Leader则会回退一个日志Entry,再次与Follower确认,直至双方一致为止。此时,Leader会将最新日志同步给Follower,从而让双方日志完全一致。

8、P2此时正式成为Leader,开始接收请求,并开始同步日志(AppendEntries RPC)

投票过程有一些限制:
单次投票:当Follower收到不同Candidate的同一Term的 RequestVote RPCs时,只会投票给第一个
仅投票给日志完整性高的Candidate:当Follower收到Candidate的RequestVote RPCs时,如果Candidate的日志完整性不如自己高,则拒绝投票
过半投票:Candidate必须有过半的投票,才能升级为Leader,从而避免脑裂

当然,也会有一些特殊情况:
系统启动:节点启动后默认为Follower,由于没有Leader,各节点很快会进入选举超时,并转换为Candidate,并发起选举。
选举失败:没有任何Candidate获得足够的票数,这样会继续进入下一轮选举,而且这个等待选票的时间,也是随机的

四、Raft算法的工作流程
当完成Leader的选举后,工作流程就比较简单了。

接收请求:
客户端向Leader发送一个写请求,比如设置键值对key1=value1。

日志复制:
Leader创建一个新的日志条目,并将其追加到自己的日志末尾。

日志同步:
Leader将这个日志条目发送给跟所有的Follower,包含了日志条目的信息以及领导者的任期号等。
Follower收到日志后,首先验证任期是否有效,如果任期有效,而且日志条目与本地日志记录兼容,则存储这个日志条目到自己的日志末尾。
跟随者在成功存储日志条目后,会向领导者发送一个确认响应(包含当前的任期号和成功标识)。

日志提交:
Leader等待Follower的确认消息,一旦收到大多数Follower的确认,它就将日志记录为“已提交”状态。
此时,Leader会向客户端返回操作成功。

应用日志:
Leader会在心跳包以及新日志复制的消息中,带上当前最新日志索引编号。
Follower接收到指令后,会将编号小于等于最新日志索引编号的日志条目,应用到自己的状态机中。
由于所有节点都按照相同的日志条目顺序执行操作,因此所有节点的状态机最终将保持一致。

五、效率提升
仅Leader接收请求:
避免集群多次通讯达成一致的过程,Leader接收并处理全部请求,然后同步给Follower。大幅提高吞吐能力。

日志压缩:
为了减少存储空间的使用,会定期进行日志压缩,保留关键的日志信息,而丢弃已经被持久化和应用的日志条目。

随机选举计时器:
通过随机时间,避免了所有节点一起发起投票,只投给自己的情况。用相对较低

单节点变更:
当增减节点的时候,保证一次只增减1个节点,可以有效的避免脑裂的出现

分布式一致性算法02:Multi-Paxos

分布式一致性算法02 Multi-Paxos算法

一、基本概念
Multi-Paxos算法,在Paxos的基础上,通过引入领导者(Leader)的概念,大幅提升了效率。

二、Multi-Paxos算法通常涉及三种角色:
Leader(领导者)/Proposer(提议者) :在Multi-Paxos中,通常会选举出一个Leader作为Proposer,负责提出提议,并尝试让多数接受者接受该提议。
Acceptor(接受者) :负责接受或拒绝提议者的提议。每个节点都可以是Acceptor,负责记录和确认提议。
Learner(学习者) :负责学习最终达成一致的提议。

三、Multi-Paxos算法的基本过程
1、初始化阶段
首先,通过Paxos算法,选择一个领导者(Leader),它负责发起全部提议。

2、准备阶段(Prepare Phase)
领导者向集群中的其他节点发送Prepare消息,这些消息包含当前的最大提议编号。
Acceptor(接受者)接收到Prepare消息后,会返回一个响应,表明它们是否已经接收到更高编号的提议。
如果领导者接收到大多数节点的响应,表示它们没有更高的提议,则可以继续下一步。

3、接受阶段(Accept Phase)
领导者根据收到的Prepare响应选择一个提议编号,并向集群中的其他节点发送Accept消息。这些消息包含提议编号和提议值。
节点接收到Accept消息后,如果该提议编号高于它们当前已接受的提议,则会接受该提议并返回确认消息。如果大多数节点确认接受该提议,则该提议被接受。

4、提交阶段(Commit Phase)
一旦提议被大多数节点接受,领导者将该提议标记为已提交,并通知集群中的其他节点。
节点接收到提交通知后,将执行该提议,并更新其状态。

5、应用阶段(Apply Phase)
最后,领导者将已提交的提议应用到状态机中,并通知集群中的其他节点。
节点接收到应用通知后,也会将提议应用到其状态机中,从而确保所有节点的状态一致。

四、举例说明
假设我们有一个分布式系统,由10个节点组成:P1、P2是提议者(Proposer),A1、A2、A3、A4、A5是接受者(Acceptor),L1、L2、L3是学习者(Learner)。

1、初始化阶段
在Multi-Paxos中,任何提议者都可以被选为领导者。
系统启动时,通过某种机制(比如Paxos算法)选举出一个新的领导者,这里假设P1被选为领导者。

2、准备阶段(Prepare Phase)
领导者P1,生成一个提议编号(例如7),向所有接受者询问,是否可以接受编号为7的提议。
接受者A1~A5收到消息后,由于提议编号7大于它们之前见过的任何提议编号,将进入承诺状态,并向P1发送可接受提议编号7的提议,并承诺不会接受任何编号小于7的提议。
【通过算法优化,其实可以节省提议编号这个阶段,直接发起提议】

3、接受阶段(Accept Phase)
当受到大多数接受者同意提议编号的消息后,P1向集群中的所有接受者发送Accept消息,提议编号7的内容为V7。
接收者收提议后,如果该提议编号高于它们当前已接受的提议,则会接受该提议并返回确认消息。

4、提交阶段(Commit Phase)
一旦P1收到来自多数接受者的已接受消息,它将向所有接受者发送提交消息,指示它们可以提交这个提议。

5、应用阶段(Apply Phase)
接受者在收到提交消息后,将提议的键值对应用到状态机中,并将结果通知学习者。

五、与Paxos算法对比
并发性:Paxos算法在每次达成共识时都需要进行两轮消息传递,这限制了它的并发能力。而Multi-Paxos通过引入领导者(Leader)的概念,允许多个提议者并发地提出提议,从而提高了并发性。
消息复杂度:在Paxos算法中,每个提议都需要两轮的通信(Prepare和Accept阶段),这增加了消息的复杂度。Multi-Paxos通过减少通信轮次,允许领导者在一轮中提出多个提议,从而减少了消息的复杂度。
实时性:由于Multi-Paxos允许并发提议,它在实时性方面通常优于Paxos算法。在Paxos算法中,每个提议都需要等待前一个提议完成后才能开始,这可能导致延迟。
容错性:Paxos算法和Multi-Paxos都具有很好的容错性,但Multi-Paxos由于其并发性,在某些容错情况下可能表现更好,例如在领导者失败时可以快速选举新领导者并继续处理提议。
实现复杂度:Paxos算法的实现相对复杂,而Multi-Paxos虽然在理论上提供了并发性的优势,但其实现也引入了额外的复杂性,如领导者选举和故障恢复机制。
优化和变种:Multi-Paxos有许多优化和变种,如Fast Paxos和EPaxos,它们通过进一步减少通信轮次或利用特定的系统特性来提高性能。而在实际应用中,许多系统采用Multi-Paxos或其变种,如Raft算法,以提高性能。

分布式一致性算法01:Paxos

分布式一致性算法01 Paxos算法

一、基本概念
Paxos是分布式一致性的经典算法,由Leslie Lamport在1990年提出。

二、Paxos算法通常涉及三种角色:
Proposer(提议者) :负责提出提议(Proposal),即向系统中提出一个值。Proposer通常是客户端,负责发起提议并分配一个不重复的自增ID给每个提议。
Acceptor(接受者) :参与决策过程,负责接收并回应Proposer的提议。每个Acceptor只能接受一个值,并且为了保证最多只有一个值被选定(Chosen),Proposal必须被超过一半的Acceptors所接受。
Learner(学习者) :负责学习最终被选定的值。Learner不参与协商过程,只是接收并记录最终被选定的值。
在实际过程中,一个节点可以同时承担1~3个角色。

三、Paxos算法的基本过程
1、准备阶段(Prepare Phase):
提议者(Proposer)选择一个提议编号(ballot number),并将其发送给所有接受者(Acceptor)。
接受者在接收到提议者的准备请求后,如果当前编号大于其已承诺的最高编号,则更新其承诺编号,并返回一个承诺(promise)给提议者,承诺中包含当前已接受的最高编号和值。

2、提议阶段(Proposal Phase):
提议者收集到多数接受者的承诺后,选择一个值(value),并结合最新的提议编号,生成提议(propose)消息发送给接受者。
接受者在接收到提议消息后,如果提议编号大于其已有的承诺编号,则接受该提议,并返回确认消息给提议者。

3、决定阶段(Decide Phase):
提议者收集到多数接受者的确认消息后,可以决定该值为最终值,并将其写入日志或状态机中。
学习者(Learner)从提议者处获取并学习最终决定的值,确保所有节点都有一致的状态。

四、举例说明:
假设我们有一个分布式系统,包含10个节点:P1、P2是提议者,A1、A2、A3、A4、A5是接受者,L1、L2、L3是学习者。

1、准备阶段:
P1提出一个提议编号,编号为1。
P1向所有接受者A1~A5发送询问,询问P1将发起编号为1提议是否可以。
A1收到提议时,并没有反馈过任何一次提议,于是反馈可以接受,并承诺,后续不会接受编号比1小的提议。A2~A4类似。

几乎同时,P2提出一个提议,编号为5。
P2向所有接受者A1~A5发送询问,询问P2将发起编号为5提议是否可以。
A1收到提议时,承诺的最小编号为1,于是反馈可以接受,并承诺,后续不会接受编号比5小的提议。A2~A4类似。

到这里,P1和P2的提议,前后都被允许提交了。当然,也有情况可能是,部分节点先收到了P2,这种情况下,P1的提议编号就无效了,需要重新拟定编号,这个编号必须单调增加。

2、提议阶段
P1收到了过半节点的提议编号反馈,向所有接受者A1~A5发送提议,告知提议编号为1的提议值为V1。
接受者收到提交消息时,已经无法接收比5小的提议,于是就拒绝P1,提议不通过。

P2收到了过半节点的提议编号反馈,向所有接受者A1~A5发送提议,告知提议编号为5的提议值为V5。
接受者收到提交消息时,反馈P2同意了5号提议。

3、决定阶段
当提议5收到过半同意反馈时(5个节点中3个以上同意),认为提议通过,各节点并将V5写入日志。
此时,学习者L1、L2、L3也会学习到V5的结果,并写入日志。

五、Paxos算法的特点
多数同意:在Paxos算法中,只有当提议者收到超过半数接受者的同意时,提议才可能被提交。
唯一性:Paxos算法保证了在任何给定的一轮中,只有一个提议可以被接受。
容错性:即使在一些节点失败的情况下,Paxos算法也能够工作。
Paxos算法的实现和理解都相当复杂,但它是许多现代分布式系统一致性协议的基础,如Raft算法等。

将被大模型+机器人严重冲击的行业

这里说的冲击严重,指的是可能导致从业人员大规模失业,而不是单纯的提升工作效率。
现在看起来,下面的部分行业从业人员,会受到较大冲击:

文字处理
1、客服人员(聊天机器人、语音机器人)
2、翻译人员(普通文件翻译)
3、文员(部分工作机会会被替代)
4、内容审核人员
5、内容创作人员(新闻转发、内容创作)
6、部分开发人员(部分代码编写人员)
7、部分法律从业者(文档整理、案例分析、合同审查)
8、部分保险从业者(部分业务员、部分核保任务)
9、部分财务人员(部分财务审计任务)

自动驾驶
1、网约车驾驶员
2、长途运输司机
3、物流人员(自动配送)

产业自动化
1、流水线工人(机器人)
2、仓库管理(无人仓储)
3、养殖人员
4、农业人员

NEOHOPE大模型发展趋势预测2405

NEOHOPE大模型发展趋势预测2405
1、规模化遇到瓶颈,资源陷阱效应愈发明显,GPT5未能按时发布,估计遇到不小的技术问题
2、垂直化趋势明显,完全通用的大模型投产比不高,而垂直化的大模型可以在一定领域内保障效果的情况下,有效降低模型训练及推理成本,
3、移动化趋势明显,以苹果为首的各厂商在努力缩减模型规模,努力提升设备推理性能,通过大模型赋能移动终端
4、具身化初现效果,无论是人形机器人,还是机器人训练,效果显著
5、多模态大模型投产低,远不如多个模态的模型整合
6、部分整合类应用已经可以赚钱,比如Perplexity等
7、下半年没有盈利能力的大模型厂商财务压力会很大
8、美国对外大模型技术封锁会更加严格

一线厂商【主观】:
1、国外闭源:ChatGPT、Gemini、Claude、Mistral
2、国外开源:Llama3
3、国内闭源:月之暗面Kimi、质谱清言ChatGLM
4、国内开源:阿里通义千问

PS:
补充其他几个不错的模型
1、绘画方向,Midjourney,SD
2、视频生成,Sora
3、文字转音频,ChatTTS

英伟达也有几个不错的模型平台
1、药物研发,BioNeMo
2、基因分析,Parabricks
3、医学影像,MONAI