go项目

1、循环使用缓存

每条日志需要开辟缓存块来存储内容，以减少频繁的内存分配与回收。日志结构体定义如下：

type MLogger struct {

	// freeList is a list of byte buffers, maintained under freeListMu.
	freeList *buffer
	// freeListMu maintains the free list. It is separate from the main mutex
	// so buffers can be grabbed and printed to without holding the main lock,
	// for better parallelization.
	freeListMu sync.Mutex

        // ...
}

已经开辟出的多个内存空间形成一个单链表，其中的freeList指向这个链表的头部。由于有多个go协程同时要操作这个单链表，如打印完日志后回收缓存，或者要求一个缓存块来存储日志内容。

首先看一下缓存的回收方法，如下：：

// putBuffer returns a buffer to the free list.
func (l *MLogger) putBuffer(b *buffer) {
	if b.Len() >= 1500 {
		fmt.Println("buffer:%d\n",b.Len())
		return // Let big buffers die a natural death（自然死）.
	}
	l.freeListMu.Lock() // 上锁

	b.next = l.freeList // 为下一个可用的buffer设置值
	l.freeList = b      // 为当前可用的freeList设置buffer

	l.freeListMu.Unlock() // 解锁
}

当开辟的缓存块过大时不进行重复利用，以释放这些内存空间。

最主要的操作就是将不需要的缓存块插入到单链表的头部，然后让freeList指针指向新插入的缓存块即可。

获取缓存块：

// getBuffer returns a new, ready-to-use buffer. （获取一个新的，可使用的缓存）
func (l *MLogger) getBuffer() *buffer {
	l.freeListMu.Lock() // 上锁

	b := l.freeList
	if b != nil {
		l.freeList = b.next
	}
	l.freeListMu.Unlock() // 解锁

	if b == nil {
		b = new(buffer)
	} else {
		b.next = nil
		b.Reset()
	}

	return b
}

在获取缓存块时需要优先考虑freeList中可用的缓存块，如果有就从链表头部取一个块返回（注意：必须调用Reset()方法，因为这个块中还缓存有上一次日志的信息），否则就创建一个新的缓存块返回。

2、创意检索算法

由于广告创意有多个定向条件，而Redis中缓存的数据结构为定向条件到创意集合的映射，如：

s_area_%d    // 地域编码，如861100表示北京

s_network_%d // 网络定向，1表示2G、2表示3G、3表示4G、4表示WIFI

s_os_%d     // 1为ios，2为android 

假设要检索出地域编码为861100、操作系统定向为ios，网络定向为WIFI的创意，而Redis中已经存在的数据集如下：

s_area_861100 = {1，4，6，7}

s_network_1 = {4，5，6}

s_os_1 = {1，5，6}

当检索创意时，新创建一个map，其key为创意ID，而值为创意出现的次数，如ID为4的创意在s_area_861100、s_network_1与s_os_1中出现了3次，则map为：

map[4] = 3

统计所有的创意出现的次数：

map[1] = 2

map[4] = 2

map[5] = 2

map[6] = 3

map[7] = 1

迭代这个map，检索出创意ID出现3次的所有创意，这些创意就是符合地域编码为861100、操作系统定向为ios，网络定向为WIFI的创意集合。

3、避免缓存穿透

为了在并发高的环境下减少IO次数，可以在本地缓存中缓存一些数据，当缓存一段时长时，重新从其它的数据源拉取最新的数据，这样减少IO的同时也能保证数据的时效性。但是当并发很高时，缓存在本地的数据在某个时刻过期，这里就会有多个请求同时做数据的拉取更新操作。如果数据源为MySQL数据库时，则无法承担很高的并发。

所以在数据过期时，需要控制只有一个请求做更新操作，其它请求等待或者直接返回，这取决于具体的业务

func (c *PowerCache) GetWithValueLoader(ctx context.Context,
     key string, valueLoader ValueLoader) (interface{}, error) {
	v, err := c.GetIfPresent(key) // 获取本地缓存中的数据
	if err == nil { // 表示从本地缓存中取出了不过期的数据，直接返回即可
		return v, err
	}
        // 代码点1
	if atomic.CompareAndSwapInt32(&c.loadFlag, 0,1) { // 进行数据更新
		v, err := c.GetIfPresent(key)
		if err == nil {
			c.loadFlag = 0
			return v, err
		}
                // 从数据源拉取最新代码同时也会更新本地缓存数据
		temp,tempErr :=c.loadWithValueLoader(ctx,key, valueLoader) // 代码点2
		c.loadFlag = 1  // 代码点3
		return temp,tempErr
	}else {
		time.Sleep(time.Millisecond * time.Duration(5))
		v, err := c.GetIfPresent(key)
		if err == nil {
			return v, err
		}
	}
	return nil,errors.New("Data Empty!") // 等待5毫秒后仍然没有从本地缓存中获取到最新的数据
}

其中涉及到一个原子API CompareAndSwapInt32，对全局的loadFlag原子性的进行比较交换。也就是loadFlag与0比较，如果相等则将loadFlag置为1。由于是原子性操作，所以只会有一个go协程调用方法后返回true。

进入后还要再一次从本地缓存中取一次数据，因为这个go协程可能在代码点1处，而另外一个更新数据的go协程已经走到了代码点3，将loadFlag设置为1。这时候这个协程直接调用GetIfPresent()方法获取数据返回即可。

代码点2在代码点3之后，避免由于本地缓存数据还未更新时，loadFlag置为1，导致更多的协程进入这个循环体内。

不更新数据的协程直接等待5毫秒后再次从本地缓存获取数据，如果取到直接返回，否则返回空。

5、流量请求分发

首先需要理解双管道类型：

func main() {

	requestChan := make(chan chan string)

	go GetResponse(requestChan)
	go SendRequest(requestChan)

	time.Sleep(time.Second) // 防止主协程过早退出，子协程跟着退出
}

func GetResponse(requestChan chan chan string) {

	// 创建一个接收信息的小管道
	responseChan := make(chan string)

	// 将这个小管道通过公有的大管理传递给其它协程
	requestChan <- responseChan

	// 从小管道中接收信息
	response := <-responseChan

	fmt.Printf("Response: %v\n", response)

}

func SendRequest(requestChan chan chan string) {

	// 从大管道中取出小管道
	responseChan := <-requestChan

	// 往小管道中写入内容
	responseChan <- "helloworld!"

}

可以将chan chan 理解为大管道嵌套的小管道。如上例子打印内容如下：

Response: helloworld!

可以使用管道特性来控制go协程，因为协程在获取管道数据时，如果获取不到数据将阻塞等待。利用这个特性结合双管道可以模拟一个协程池，类似于线程池。这样就可以重复利用协程及管道来减少创建协程带来的性能损耗了。

先来参阅一篇文章，如下：

http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/

其基本的架构如下图：

多个Request将任务放入了管道中，Dispatcher从管道中取出任务并从WorkerPool的大管道中取出一个Worker对象，将任务放入worker对象的管道JobChannel中。有几点值得注意：

（1）在WorkerPool中取出的Worker对象，这个Worker对象的JobChannel管道后监听的go协程一定是阻塞等待的，也就是说go协程没有其它的任务在执行。

（2）Dispatcher从大管道中取Worker对象，当这个Worker对象中的Jobchannel被协程处理完后，这个协程负责再次将这个Worker对象放入WorkerPool中。

AdExchange由于对请求处理的时间要求比较苛刻，并且要对多个返回结果进行筛选，所以架构与上面有所不同。

这个架构没有JobQueue这个队列，而Dispatcher也不是单个协程，而只是一个Dispatcher函数。所有的请求来时，由于每个请求都由一个go协程来处理，所以让这些go协程尽可能的多做与自身相关的任务，如将自己的Job分发出去，减少由单个Dispatcher分发带来的风险，提升分发效率。

初始化一个指定大小的线程池，代码如下：

func init(){
	var MaxWorker = 200
	WorkerPool = make(chan chan Job, MaxWorker)
	for i := 0; i < MaxWorker; i++ {
		worker := NewWorker(i+1, WorkerPool)
		worker.Start()
	}
}

调用了worker对象的Start()函数，这个函数的实现如下：

func (w Worker) Start() {
	go func() {
		for {
			// 处理任务的协程负责将w.JobChannel重新放回大管道内
			w.WorkerPool <- w.JobChannel

			select {
			case job := <-w.JobChannel:
				 // 处理具体的job任务
			case <-w.QuitChan:
				return // we have received a signal to stop
			}
		}
	}()
}

Start()启动了一个协程，将Worker对象的JobChannel放入大管道内，表示这个协程没有在做任务，而是在监听JobChannel。

当Dispatcher从大管道内取出一个w.JobChannel时，往其中放入Job对象，这样上面的协程就能接收到任务，处理具体的Job任务了，处理完成后再将这个JobChannel放回大管道，供Dispatcher继续获取分派任务。　　　

如Dispatcher分派任务，如下：

for _, val := range jobs {
		select {
		case worker := <-WorkerPool:
			worker <- val
		case <-time.After(time.Millisecond * time.Duration(5)):
			return nil, errors.New("WorkerPool Blocking!")
		}
}

从WorkerPool中取可用的JobChannel，如果取不到表示线程池中所有的协程都在做任务，已经没有空闲的协程了。

这样做的好处有：

（1）分离业务代码，如上代码分离了请求的分发、结果的筛选与请求的处理业务

（2）高效的并发模型 实现了线程安全，同时可以在每个协程内缓存数据块，无锁操作map等等