9 29
Postgresql主从异步流复制方案

数据库的备份工作在日常生产中极为重要,如果你咨询一个DBA如何才能设计出高可用的数据备份与恢复方案,相信很多人都会从架构上给出很多容灾的意见。但归根到底,如果业务环节中数据库还牵涉到分布式环境,我认为一个好的方案需要达到三大要求:

  • 多副本
  • 持久化
  • 一致性

日常架构设计中,我们不仅要保证数据额的成功备份,还要保证备份的数据可以快速恢复。在众多备份恢复可靠性方案中 主从复制 技术,可以说是最常见的实现,本文主要是介绍postgresql主备数据库的异步流复制的环境搭建与主备切换的操作实践,除了能把一些基础的原理运用在日常的数据库运维中,也可以加深对Postgresql数据库的底层知识了解。

7 22
go同步之条件变量

Go的标准库中有一个类型叫条件变量:sync.Cond。这种类型与互斥锁和读写锁不同,它不是开箱即用的,它需要与互斥锁组合使用:


// NewCond returns a new Cond with Locker l.
func NewCond(l Locker) *Cond {
    return &Cond{L: l}
}

// A Locker represents an object that can be locked and unlocked.
type Locker interface {
    Lock()
    Unlock()
}
5 31
consul集群搭建与Golang服务发现示例

传统单机应用动态性不强,不会频繁地更新和重新发布,也较少地进行自动伸缩。但随着互联网分布式系统的普及,服务与服务之间的伸缩性和可扩展性的要求也越来越大。为了满足服务的垂直和水平的扩张,以往一般使用预定义的端口配置服务,当新的服务需要上线或当期服务需要冗余扩展的时候,我们需要静态化地“注册”相关ip与端口信息到一个地方,再通过程序之间定时“更新”的方法去同步信息,但这种手段问题是非常多的,例如我们需要连接kafka的master的时候,如果服务信息发生变更,客户端是很难知道的。其中一个简单粗暴的方法是配置hosts文件,使用预定义的“域名”作为服务的连接依据,但这样也是麻烦的,服务变更的时候,要手动更改hosts文件,当服务器上的服务相对多的情况下,维护量就想当恐怖了。

其实就一句话:服务多,问题多

5 4
golang reflect实践

之前看过很多Go技术的文章和一些技术群里面的交流,主流意见都是认为反射(reflect)是导致性能的主要元凶,叫开发者少用为妙;主要是他们使用反射的业务场景离不开下面的情况:

  • reflect涉及到内存分配以及后续的GC

  • reflect实现里面有大量的枚举,也就是for循环,比如类型之类的

一开始我也“遵循”的,直到最近项目需要,越来越多的场景需要用到反射机制才能灵活应对,毕竟某些情况某些情景下性能不是特别高的要求,模块的灵活性扩展性(够有能力处理各种输入类型,而这些类型可能无法共享同一个接口,也可能布局未知)才是占据重要的位置。反射不但指计算机程序在运行时(Run time)可以访问、检测和修改它本身状态或行为的一种能力,也是元编程的一种形式,我们常见的RPC库或者一些ORM框架基本都是使用反射来实现核心的功能,所以本文主要是最近使用反射的一些总结

前一页 后一页