tracker服务功能实现分析

tracker服务端初始化：tracker\fdfs_trackerd.c
1、tracker_service_init，启动work_thread_entrance处理线程，该线程处理使用了触发器机制
   A、从pThreadData->pipe_fds[0]中获取数据，然后通过event_set/event_base_set注册的recv_notify_read进行处理，实现在track_nio.c中client_sock_read->tracker_deal_task，该任务为主处理线程，从fast_task_info->data中提取TrackerHeader的cmd分别进行处理
   B、client_sock_write发送响应消息

2、如果有配置tracker_httpd_start，启动httpd_entrance线程，调用generic_handler，处理接入的HTTP请求

3、sched_start，启动sched_thread_entrance线程，调用直接设置的scheduleArray中ScheduleEntry结构的task_func处理，初始化设置四个处理函数log_sync_func/tracker_mem_check_alive/tracker_write_status_to_file/log_notify_rotate
   A、log_sync_func 将前面的日志写入，并将原日志文件log_rotate更名保存。
   B、tracker_mem_check_alive 清点处于活动状态和非活动状态的服务器，非活动服务器置位FDFS_STORAGE_STATUS_OFFLINE

4、tracker_relationship_init，启动relationship_thread_entrance线程，包含一个relationship_select_leader/relationship_ping_leader的过程，意思就是在没有主用的情况下，定时MAX_SLEEP_SECONDS监测或选择主用的track服务器。
这个选择的算法很简单。在所有获取的服务器列表中根据TrackerRunningStatus状态qsort排序后从比较函数relationship_cmp_tracker_status中选择领导力强、时间最长、重启间隔最短的那个服务器。
不过这个选择的算法，只有500行代码做主备HA显然是不够的。本人开发过一个HA，代码上万行，解决方案个人觉得都是马马乎乎。这个算法中，至少有些问题无法回避，比如各个服务器看到的服务器列表不一致怎么办？如何纠正某个服务器的初始化选择的错误等。当然，作为经济的解决方案，这样做应该可以应付大多数场景。

5、tracker_accept_loop不断接入通信连接，然后通过管道pThreadData->pipe_fds触发上面步骤1中的work_thread_entrance处理

6、tracker_terminate_threads/HTTP、内存、服务、主备HA卸载，回收以上各个过程的资源。再次为大师叫好，良好编程的典范。本人阅读很多开源代码，也在实际工作中处理过无数资源、内存、句柄泄露问题，很难得看到有这么清楚的资源处理。

本文到此，先告一段落。读者可能认为行文逻辑有些跳跃，不知所云，但实际上基本功能已经清楚了。因为最近工作有些小麻烦，等解决了问题后面我再重新输理一遍，完善一下描述。