storage服务功能实现分析之一

storage服务功能分析，从初始化流程开始，各个功能单元落地。

1、storage_service_init    注册的g_storage_thread_count个任务池，每个任务一个管道，后续storage_accept_loop会用。work_thread_entrance中通过event_set设置接收处理函数storage_recv_notify_read，获取accept的套接字进行处理。如果出现错误接收处理任务退出时，步骤6的storage_accept_loop会继续接入新的连接继续处理。

2、sigaction(SIGUSR1,SIGHUP,SIGPIPE,SIGINT) 异常信号处理，本人最熟悉的机制，捕获系统异常用的。我们自己的项目做的更完善，淘宝也必然有进一步的分析和定位处理机制。

3、tracker_report_thread_start              下节专门描述，状态监控上报处理。作为一个分布式文件系统的数据服务，架构必然是控制面和业务面分离。控制面就是系统配置信息的上传下达、信息同步、状态监测等多节点整体运作协同的流程处理；业务面就是用户看到的文件具体操作在系统内部的实际处理流程。虽然大部分我们都关注业务面处理，其实对于有经验的设计者来说，控制面(有时也称管理面)才是更值得关注的部分。我的项目经验是无论哪个系统开发，控制面工作量占绝对大多数，一般是6成以上。

4、sched_start             启动sched_thread_entrance线程，调度的对象是ScheduleContext->ScheduleArray->ScheduleEntry记录的TaskFunc。这个机制类似于Linux内核里的event机制，应用触发一个运行事件，在固定的events内核线程中完成。目前只有一个应用场景，就是在本地为trunk server时使用sched_add_entries处理trunk_create_trunk_file_advance，建立一个64M大小的数个trunk_file。

5、storage_dio_init        storage_dio.c模块的入口。启动多个dio_thread_entrance任务，守护在task_queue上执行指定操作。这些操作时用storage_dio_queue_push加入的 dio_read_file/dio_write_file/dio_discard_file/storage_do_set_metadata/dio_delete_trunk_file。单独设立IO线程的目的应该是避免命令接收线程被阻塞，影响处理效率。IO独立并实现并行处理是所有分布式系统的设计方法。

简单一例说明，同步创建文件

storage_deal_task(STORAGE_PROTO_CMD_SYNC_CREATE_FILE)->storage_sync_copy_file->storage_write_to_file->storage_dio_queue_push(dio_write_file)/storage_sync_copy_file_done_callback

6、storage_accept_loop     accept接入一条TCP连接，记录到fast_task_info结构中，通过管道发送到其它任务处理TCP接收。storage_accept_loop接入新的连接后，通过event机制进行处理。

storage_recv_notify_read->client_sock_read->storage_deal_task根据消息命令cmd类型进行实际的数据处理。

7、fdfs_binlog_sync_func   处理到这里，说明进程马上要退出，脏日志数据记录刷新到磁盘介质中。后面都是收尾的处理，包括tracker_report、storage资源等destory，设计到此完美收官。看得出该作者编码水平很高，我认为代码水平不是看技巧，其实就是看这些细节的处理。