tracker服务器架构分析

初始化线程间信号量和线程池
tracker_service_init->work_thread_entrance
其主要处理：按接收通知消息处理
recv_notify_read->event_set(client_sock_read)->client_sock_read->tracker_deal_task
这里面有所有客户端以及storage发起的客户端请求消息处理

g_check_file_duplicate说明有文件备份存在，需要和ServerArray内的所有服务器握手。

common\sockopt.c 通信使用TCP套接字，epoll/select接收数据报文
通信队列缓存管理tracker\fast_task_queue.c，队列为g_free_queue，初始化free_queue_init，删除free_queue_destroy
申请内存：struct fast_task_info数据结构free_queue_pop->task_queue_pop，释放内存：free_queue_push，包括大内存主动释放功能，大于min_buff_size的申请内存直接释放。
free队列是共享的，各个任务队列是区分开的。相同方式申请，分别使用。

通信主要使用libevent组件，这篇文章有介绍，了解一下：

libevent简单介绍:http://blog.csdn.net/mafuli007/article/details/7476014

业务处理架构

以一个fastDFS tranker客户端查询访问流程为例简单说明：
客户端：
fastdfs_tracker_query_storage_store->php_fdfs_tracker_query_storage_store_impl->tracker_query_storage_store_with_group/tracker_query_storage_store_without_group->tcpsenddata_nb(TRACKER_PROTO_CMD_SERVICE_QUERY_STORE_WITH_GROUP_ONE/TRACKER_PROTO_CMD_SERVICE_QUERY_STORE_WITHOUT_GROUP_ONE)/fdfs_recv_response
使用同步等待的方式，等待服务端的响应消息

服务端：
tracker_deal_task(TRACKER_PROTO_CMD_SERVICE_QUERY_STORE_WITH_GROUP_ONE)->tracker_deal_service_query_storage
A、通过bsearch查询g_groups组内名字匹配的FDFSGroupInfo
B、tracker_check_reserved_space计算保留空间
C、tracker_get_writable_storage，从当前写的服务器（应为storage）中的下一个开始，current_write_server++先
D、将StoreGroup中所有的active_servers的IP地址写入响应消息体中，并返回给客户端