前文中对标记删除算法的介绍更多还是偏理论性质的。实践中,为了更好地满足现实的场景及需求,还需要对算法进行大量的调整。举个简单的例子,我们来看下JVM需要记录哪些信息才能让我们得以安全地分配对象空间。
碎片及整理(Fragmenting and Compacting)
JVM在清除不可达对象之后,还得确保它们所在的空间是可以进行复用的。对象删除会导致碎片的出现,这有点类似于磁盘碎片,这会带来两个问题:
前文中对标记删除算法的介绍更多还是偏理论性质的。实践中,为了更好地满足现实的场景及需求,还需要对算法进行大量的调整。举个简单的例子,我们来看下JVM需要记录哪些信息才能让我们得以安全地分配对象空间。
JVM在清除不可达对象之后,还得确保它们所在的空间是可以进行复用的。对象删除会导致碎片的出现,这有点类似于磁盘碎片,这会带来两个问题:
问题排查除了最重要的解决思路和逻辑推导能力外,工具也是不可缺少的一部分,一个好用的工具可以事半功倍,甚至在某些情况下会因为没有相应的工具而压根就没法继续进行下去,这篇文章就来讲讲在排查Java问题时通常要用到的一些工具(:这种文章值得收藏,看一遍其实很容易忘)。
日志相关工具
查问题的时候会非常依赖日志,因此看日志的相关工具非常重要,通常的话掌握好tail,find,fgrep,awk这几个常用工具的方法就可以,说到这个就必须说关键的异常和信息日志输出是多么的重要(看过太多异常的随意处理,例如很典型的是应用自己的ServletContextListener实现,很多的Listener实现都会变成往外抛RuntimeException,然后直接导致tomcat退出,而tomcat这个时候也不会输出这个异常信息,这种时候要查原因真的是让人很郁闷,尽管也有办法)。
日志的标准化也非常重要,日志的标准化一方面方便像我这种要查各种系统问题的人,不标准的话连日志在哪都找不到;另一方面对于分布式系统而言,如果标准化的话是很容易做日志tracing的,对问题定位会有很大帮助。
第三个版本,jAlbum完整版差不多完工了:https://github.com/shentar/jAlbum/releases/tag/jAlbum_0.1.3。
最后解决了文件系统监控的问题。利用Java1.7封装的文件系统的通知回调机制,实现对指定目录的递归监控,避免每次全盘扫描性能太低的问题。
注意对于linux系统对于单个用户能够监听的inotify对象个数做了限制,一般是限制为8192,因此需要修改系统内核的配置:在/etc/sysctl.conf文件中,新增一行:fs.inotify.max_user_watches=1000000,表明将该限制修改为100万个。下次重启后会生效,如果希望当前立即生效,则需要执行命令:sysctl –p 。
对于WatchService,只监控当前目录的变化,当前目录下新增文件或者文件夹时,当前文件夹会有修改事件或者创建事件,但是再下一层的文件夹或者文件发生变更时,并不会有任何事件,因此如果要监控指定的文件夹,需要递归监控到最后一层。没有验证文件系统的notify机制对进程性能和文件系统性能的影响,在树莓派上面简单验证了下,能够非常及时的发现新增文件,进程CPU和内存也没有明显的增加。终于解决了每次都有依赖全盘扫描一遍文件才能发现新增的文件的问题。
具体代码请参见源码中的DirWatchService类。
在基于自攒的PC搭建了Home NAS系统之后,使用btsync工具将家里的各个终端的照片和视频集中备份到了Home NAS。主要是台式电脑、笔记本和家人的各个手机上面的照片、拍摄视频、微信聊天视频和朋友圈短视频等。备份好之后,发现各个设备上面的图片存放时并没有非常严谨的分类,并且有大量的重复照片,就想着做一个照片、视频管理系统放在Home NAS上面持续运行并提供相册服务。系统前端提供web访问接口,浏览器可以直接访问,后台生成一个简易相册库,以WEB页面的方式供各个终端查看和下载照片。 想到哪儿做到哪儿,并没有非常详尽的需求分析分析和软件设计。最终实现了如下功能:
软件架构图:
源码托管在此GIT服务上面:jAlbum(https://git.codefine.site:3000/Shentar/jAlbum) ,欢迎fork、提交issue和修改代码。
以下是适用于X86 Windows系统和Linux系统的软件包。0.3.1及之前的版本运行环境要求Java 1.8,JDK或者JRE都可以;0.3.2版本及其之后的版本仅支持JDK11环境。下载软件包后,解压缩,完成必须的配置即可运行。
版本 | 发布时间 | 更新说明 | 下载链接 |
0.3.3 | 27 Nov 2021 | 1、支持上报metrics到stastd-exporter。 | 下载 |
0.3.2 | 22 May 2021 | 1、升级JDK版本到JDK11; 2、升级Jetty版本; 3、支持HTTP2。 | 下载 |
0.3.1 | 24 Feb 2021 | 1、缩略图显示优化; 2、支持整合图片到单独目录; 3、支持本地自建的人脸识别服务。 | 下载 |
0.3.0 | 3 Mar 2018 | 1、支持使用Google Analytics跟踪访问记录; 2、解决若干已知bug。 | |
0.2.9 | 25 Nov 2017 | 1、支持备份数据到Huawei Cloud OBS对象存储。 | |
0.2.8 | 18 Nov 2017 | 1、支持HTTPS访问; 2、解决响应中重复HTTP头域Date和Expire问题; 3、解决鉴权Bug。 | |
0.2.7 | 19 Jul 2017 | 1、新增“风景”页; 2、使用Maven管理项目; 3、其他问题解决。 | |
0.2.6 | 19 May 2017 | 添加访问权限控制,相册放在外网访问时,发放token才能访问,避免照片被陌生人访问,如:搜索引擎抓取照片。 | |
0.2.5 | 7 May 2017 | 性能提升。 | |
0.2.4 | 3 Apr 2017 | 1、可靠性功能问题解决。 2、性能提升。 | |
0.2.3 | 17 Mar 2017 | 增加人像识别和按照任务归集照片功能。 | |
0.2.2 | 29 Jan 2017 | 1、增加后台同步照片到AmazonS3服务端实现。 2、修改若干重复文件检测bug。 | |
0.2.1 | 8 Jan 2017 | 解决问题:Chrome浏览器Ranges下载时第一个Range时不按照协议实现收取所有数据,最终在页面有多个Video时会导致浏览器挂死。单页面多个Video时,提取视频文件的缩略图呈现。 | |
0.2.0 | 6 Nov 2016 | 1、新增Video的支持,支持对MP4视频文件呈现; 2、修正稳定性和功能细节的bug。 | |
0.1.9 | 14 Aug 2016 | 1、PC端浏览器,增加键盘翻页,左方向键翻上一页,右方向键翻下一页。 2、改进“照片发现”性能,最快在20秒内新增照片可以呈现到页面上。 3、其他bug解决。 | |
0.1.8 | 5 Aug 2016 | 1、优化照片隐藏逻辑,当隐藏的照片被移动或者删除后又添加时,也不会被显示出来。 2、适配移动终端浏览器,实现触控滑动照片翻页。 | |
0.1.7 | 31 Jul 2016 | 自动识别图片的旋转角度,在前端呈现时自动适应浏览器并旋转到正确的方向。 | |
0.1.6 | 24 Jul 2016 | 修正若干bug。使用按钮代替超链接来导航相册。 | |
0.1.5 | 21 Jul 2016 | 1、增加前端照片旋转功能。 2、完善照片删除功能。 3、解决稳定性bug。 | |
0.1.4 | 18 Jul 2016 | 新增删除照片功能。在单张照片显示的页面上面可以点击删除链接“删除”该照片,该照片之后不会再显示,当然照片还存在于磁盘中,只是不再显示。 | |
0.1.3 | 10 Jul 2016 | 1、增加文件系统监控,利用文件系统的notify机制及时处理新的文件变更; 2、不再定时全盘扫描,只在启动时进行全盘扫描; 3、定时根据base表的变更情况刷新辅助表及时呈现新增照片。 | |
0.1.1 | 2 Jul 2016 | 1、支持缩略图; 2、优化编译脚本; 3、增加配置文件。 | |
0.1.0 | 23 Jun 2016 | first release. |
在Git仓库下载最新的版本的代码包,执行如下命令编译安装,注意需要使用JDK 11版本,其他版本未适配,不保证编译和启动成功 ^_^
cd jAlbum
mvn install
cd distribute
sh jalbum.sh start
如果是Windows系统则运行start.bat批处理文件启动,启动成功界面为:
直接下载编译好的软件包,参考软件包下载。
服务端默认监听2148(http)和5443(https)端口,使用浏览器访问即可,如在本机访问,直接使用http://127.0.0.1:2148即可访问。针对android系统,在相册主页有apk可以下载安装,在设置界面指定服务端地址也可访问。
最新版本主页截图:
视频合集页面截图:
根据人像识别结果进行照片归集页面截图:
停止运行jAlbum,将新版本的软件包中根目录下的jalbum.xml、log4j.xml、keystore和dedup.db文件删除,然后将剩下的所有文件和目录覆盖到原运行目录。重新启动jAlbum即可。
当前支持的照片文件类型有:
<picfilesuffix>
<suffix>jpg</suffix>
<suffix>jpeg</suffix>
<suffix>png</suffix>
</picfilesuffix>
将上述代码添加到jalbum.xml的config标签内即可。
当前仅支持mp4文件的分析和呈现,并且需要先安装ffmpeg工具。在ffmpeg官方站点下载当前操作系统的工具,将ffprobe和ffmpeg可执行文件置于系统PATH变量所指向的路径下,如:C:\Windows目录下。jAlbum运行中会调用该工具分析MP4视频文件。 另外,在jalbum.xml内,picfilesuffix标签内增加如下内容:
<suffix>mp4</suffix>
<minfilesize>51200</minfilesize>
<maxfilesize>512000000</maxfilesize>
此配置用于定制最小文件和最大文件大小。
指定jAlbum监控的目录:
<inputdir>
<dir>D:\\</dir>
<dir>C:\\</dir>
</inputdir>
可以配置多个目录。注意Windows系统下,需要使用双斜杠来作为目录分隔符。 指定jAlbum排除某些特定目录,对于某些系统目录或者出于隐私保护而不希望呈现的目录,可以使用此配置排除监控:
<excludedir>
<dir>C:\\windows\\</dir>
<dir>C:\\Program Files\\</dir>
<dir>./</dir>
</excludedir>
指定缩略图存放目录:
<thumbnaildir>./thumbnail</thumbnaildir>
thumbnaildir标签用于指定缩略图文件存放的目录。
maxpicsperonepage标签用于定制单个页面中显示的媒体文件的数量。
threadcount标签用于定制任务并发数量。可以根据当前系统的CPU性能定制该数值。 hashalog用于定制计算照片文件和视频文件的HASH算法,常用的有MD5, SHA-256, SHA-1,一般而言HASH算法强度越高计算要求也越高,对于普通家用照片剔重,MD5比较合适。
首先需要到旷视科技申请API Key,然后在jalbum.xml中配置如下标签:
<Facer>
<ak></ak>
<sk></sk>
<facesetprefix></facesetprefix>
<maxfacescount></maxfacescount>
</Facer>
其中ak填写为API Key,sk填写为API Secret。facesetprefix为face set的前缀,当有多个应用使用同一个账号时,可以使用此前缀做区分。maxfacescount为相册人像主页上呈现的人物的个数。
jalbum支持将数据备份到华为云对象存储和亚马逊的S3对象存储。当备份到华为云时,默认使用归档存储级别。两种备份目的端的使用是完全相同的。
<s3>
<bucketname></bucketname>
<ak></ak>
<sk></sk>
<useHttps></useHttps>
</s3>
<HuaweiOBS>
<bucketname></bucketname>
<ak></ak>
<sk></sk>
<useHttps></useHttps>
</HuaweiOBS>
其中,bucketname指定用于备份的容器,ak、sk分别为对象存储服务提供的访问凭据,需要到相应的对象存储服务上申请。useHttps指定是否使用https协议上传数据,为提高性能,如数据安全性要求不高,可以直接使用http协议传输。
jalbum本身支持access日志,有log4j.xml配置。可以自行根据需要修改log4j.xml定制日志格式和存放目录。 另外,当相册在互联网上面开放访问时,可以配置Goolge Analytics,实现对访问进行统计。只需要将Goolge Analytics提供的ID写入如下配置:
<GoogleAnalyticsID></GoogleAnalyticsID>
如果配置为空,则不启用统计。
当jalbum开放到互联网访问时,为了避免搜索引擎以及其它爬虫工具抓取照片,系统默认开启了需要输入Token方式来访问。 当不需要此权限控制时,可关闭Token访问,配置如下标签:
<accessAuth>true</accessAuth>
在开启权限控制时,相册提供后台页面和管理员登录方式来管理Token,启动后台备份和立即刷新数据等操作。
在本地登录时,可以管理Token,使用浏览器或者curl -X GET ${url}命令访问如下地址:
为安全起见,当前jAlbum本身只监听127.0.0.1上的http端口,如果需要外网访问,需要自行添加Nginx反向代理,推荐如下配置:
server
{
listen 5443 ssl http2;
server_name yourdomainname.com;
ssl_certificate /path/of/your/server/cert;
ssl_certificate_key /path/of/your/private/key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
location / {
proxy_pass http://127.0.0.1:2148/;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr; # it is important to add this header.
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
}
location ~ /\. {
deny all;
}
access_log on;
}
当使用管理员Token登录,或者在本地登录时:
Jetty 8 长连接的超时断开连接的机制:超时连接机制针对IO传输过程中的数据阻塞时间超过一定阈值时,断开该连接。阻塞指当前处于数据传输阶段,但是连续指定时间内都没有发出或者接收到任何数据时,Jetty系统断开该连接。强调一下,只有在数据传输过程中才会有超时机制。在服务端处理已经收到的数据时是不会检测该超时时间的。
下面看一下具体的代码实现。在jetty 8.1.17版本中,由以下代码控制一个连接的空闲、非空闲和断开检查方法,在SelectChannelEndpoint类中:
陈明,微信高级工程师、朋友圈负责人,2012年加入微信后台团队,负责微信后台核心服务的研发,包括朋友圈、即时通信、基础设施等。他获得清华大学计算机系学士和博士学位,研究方向是分布式系统。在加入微信前,他在腾讯搜索和微软亚洲研究院工作多年,内容包括搜索架构与分布式存储等。
截止到2015年7月,微信每月活跃用户约5.49亿,朋友圈每天的发表量(包括赞和评论)超过10亿,浏览量超过100亿。得益于4G网络的发展,以上数据仍有很快的增长,而且相对于PC互联网时代,移动互联网时代的峰值要来得更加凶猛。比如,2015年元月的流量到了平时的2倍,而峰值则达到了平时峰值的2倍,相当于平时正常流量的5倍,这对整个系统的考验是很残酷的。本次分享将简单介绍微信后台团队的开发模式、微信朋友圈的架构以及在性能上的一些工作,供各位参考。
随着 HTTP/2 的逐渐普及,以及国内网络环境越来越糟糕(运营商劫持和篡改),HTTPS 已经开始成为主流。HTTPS 在 TCP 和 HTTP 之间增加了 TLS(Transport Layer Security,传输层安全),提供了内容加密、身份认证和数据完整性三大功能,同时也给 Web 性能优化带来新的挑战。上次写的「使用 BoringSSL 优化 HTTPS 加密算法选择」一文中,我介绍了如何针对不同平台启用最合适的传输加密算法。本篇文章我打算继续写 HTTPS 优化 —— TLS 握手优化。
TLS 的前身是 SSL(Secure Sockets Layer,安全套接字层),由网景公司开发,后来被 IETF 标准化并改名。通常没有特别说明时,SSL 和 TLS 指的是同一个协议,不做严格区分。
Linux kernel成功的两个原因:(1)灵活的架构设计使得大量的志愿开发者能够很容易加入到开发过程中;(2)每个子系统(尤其是那些需要改进的)都具备良好的可扩展性。正是这两个原因使得Linux kernel可以不断进化和改进。
分层结构的原则:the dependencies between subsystems are from the top down: layers pictured near the top depend on lower layers, but subsystems nearer the bottom do not depend on higher layers.
这种子系统之间的依赖性只能是从上到下,也就是在上图中位于顶层的子系统依赖位于底层的子系统,反之则不行。
之前有几篇文章已经关注过加密解密证书和HTTTPS的一些基本原理。HTTPS、SSL与数字证书介绍,公钥私钥加密解密数字证书数字签名详解。这里想探讨一下单一的web服务中多个域名共享一个证书或者使用多个证书进而使用多域名的HTTPS的问题。
在《HTTPS、SSL与数字证书介绍》这篇文章中介绍了,证书是在SSL握手阶段交换的,而域名是在HTTP请求的Header中传输到服务端的,HTTP协议在SSL之上,而两层协议之间是无法共享数据的。因此证书是在建立HTTP的Session之前就已经决定了。但是有越来越多的场景需要同一个Server监听多个域名,对外呈现多个入口。而我们知道,客户端会校验证书中的网址、颁发者的公钥和过期时间等信息。后面两个可以通过付费到具有公信力的颁发机构颁发证书的方式解决。网址匹配有点麻烦,网址一般填写在证书的Common Name上面,因此网址与域名是一一对应的关系。而多个不同的域名可以解析成同一个IP地址,这样如何做到给每个域名都绑定不同的证书?是给每个域名都分配一个服务器,绑定单独的IP地址吗?但是在规模不大的情况下只部署有限的服务器。