tracker

FastDFS是一款类Google FS的开源分布式文件系统，它用纯C语言实现，支持Linux、FreeBSD、AIX等UNIX系统。它只能通过 专有API对文件进行存取访问，不支持POSIX接口方式，不能mount使用。准确地讲，Google FS以及FastDFS、mogileFS、 HDFS、TFS等类Google FS都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。 1、FastDFS架构图 图1：FastDFS架构图 1）Tracker cluster中各个tracker server相互独立，不进行相互通信。 2）Storage cluster中各个storage组（Volume1,Volume2...）相互独立，不进行相互通信，也就是说各个组之间保存的数据是不相同的。但是各个组中的storage server之间是属于互相备份的关系，也就是说storage server之间保存相同的数据。 3）每个storage server会启动一个单独的线程主动向Tracker cluster中每个tracker server报告其状态信息，包括磁盘使用情况，文件同步情况及文件上传下载次数统计等信息。 2、文件上传和下载的时序图 图2：文件上传时序图 1）Client通过Tracker server将文件上传到Storage server。 2）Tracker

一、FastDFS介绍 FastDFS开源地址： https://github.com/happyfish100 参考： 分布式文件系统FastDFS设计原理 参考： FastDFS分布式文件系统 个人封装的FastDFS Java API： https://github.com/bojiangzhou/lyyzoo-fastdfs-java 1、简介 FastDFS 是一个开源的高性能分布式文件系统（DFS）。 它的主要功能包括：文件存储，文件同步和文件访问，以及高容量和负载平衡。主要解决了海量数据存储问题，特别适合以中小文件（建议范围：4KB < file_size <500MB）为载体的在线服务。 FastDFS 系统有三个角色：跟踪服务器(Tracker Server)、存储服务器(Storage Server)和客户端(Client)。 　　Tracker Server ：跟踪服务器，主要做调度工作，起到均衡的作用；负责管理所有的 storage server和 group，每个 storage 在启动后会连接 Tracker，告知自己所属 group 等信息，并保持周期性心跳。 　　Storage Server ：存储服务器，主要提供容量和备份服务；以 group 为单位，每个 group 内可以有多台 storage server，数据互为备份。 　　Client

因为工作中再次需要用到FastDFS做多机分布式集群，在此做个笔记，便于大家学习参考，因不同机器的基础软硬件环境不一样，整个分布式集群搭建配置过程可能会有各种坑，热情填坑即可^0^ 一、应用场景说明 1.FastDFS主要解决了大容量的文件存储和高并发访问的问题，文件存取时实现了负载均衡。 2.FastDFS实现了软件方式的RAID，可以使用廉价的IDE硬盘进行存储 ，支持存储服务器在线扩容。 3.FastDFS特别适合大中型网站使用，用来存储资源文件（如：图片、文档、音频、视频等等。 二、服务端架构 由于公司提供服务器有限，web服务器和redis就这样安装了，web服务器和redis服务器可用另外服务器做集群扩展，同时tracker和storage也可以横向扩展 注：双tracker时，其中一个是候补，若master挂掉后，候补会自动接任. 三、环境搭建过程 先在两台服务器上分别搭建单机配置，具体参考： http://my.oschina.net/xiejunbo/blog/380555 单机搭建完成后，修改配置并测试： -------------------------------------------- 192.168.1.109配置(其它配置项默认) :------------------------------------------------ tracker

I’m working with python 2.7 and opencv 3.1 I want to run a code for tracking objects by this: import cv2 import sys if __name__ == '__main__' : # Set up tracker. # Instead of MIL, you can also use # BOOSTING, KCF, TLD, MEDIANFLOW or GOTURN tracker = cv2.Tracker_create("MIL") # Read video video = cv2.VideoCapture("videos/chaplin.mp4") # Exit if video not opened. if not video.isOpened(): print "Could not open video" sys.exit() # Read first frame. ok, frame = video.read() if not ok: print 'Cannot read video file' sys.exit() # Define an initial bounding box bbox = (287, 23, 86, 320) # Uncomment

原创作者：高鹏 本文提要 本节将解释 MySQL 层详细的提交流程，但是由于能力有限，这里不可能包含全部的步骤，只是包含了一些重要的、并且我学习过的步骤。 我们首先需要来假设参数设置，因为某些参数的设置会直接影响到提交流程，我们也会逐一解释这些参数的含义。 本节介绍的大部分内容都集中在函数 MYSQL_BIN_LOG::prepare和MYSQL_BIN_LOG::ordered_commit 之中。 一、参数设置 本部分假定参数设置为： binlog_group_commit_sync_delay：0 binlog_group_commit_sync_no_delay_count：0 binlog_order_commits：ON sync_binlog：1 binlog_transaction_dependency_tracking：COMMIT_ORDER 关于参数 binlog_transaction_dependency_tracking 需要重点说明一下。我们知道 Innodb 的行锁是在语句运行期间就已经获取，因此如果多个事务同时进入了提交流程（prepare阶段），在 Innodb 层提交释放 Innodb 行锁资源之前各个事务之间肯定是没有行冲突的，因此可以在从库端并行执行。在基于 COMMIT_ORDER 的并行复制中，last commit 和 seq