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