数据降维算法
如何实现降维
PCA(主成分分析)
PCA可以把可能具有相关性的高维变量合成线性无关的低维变量,称合成后的低维变量为主成分。主成分可以代替原来的高维变量很好的反映数据的分布,而且减少了无关的变量。
不严格地说,主成分可以看做一组特征向量。通过计算数据集中两两变量之间的协方差得到的协方差距阵,再对协方差矩阵求特征值和特征向量,按照特征值的大小排序得到一组特征向量U,确定主成分的个数m(m<d),从U中按特征值大小从大到小取m个特征向量,这m个特征向量对应的属性个数即构成了降维后的数据空间维度的大小。
PCA降维的步骤:
- 求样本数据(d维,n个样本)对应的每个变量X的均值,并将所有的样例都减去对应的均值。数据中心化的过程。
- 计算协方差矩阵
- 求协方差矩阵对应的特征值和特征向量。
- 将特征值按照从大到小的顺序排列,选择其中的m的特征值,并将对应的m个特征向量作为列向量组成变换矩阵。
- 用原来的d维的样本数据乘以变换矩阵即得到降维后n x m的矩阵,维度从d维降到m维。
集群相关知识
Marathon
应用重启
- 重启方式:marathon会根据mesos发送过来的offer把该服务在任意一台服务器上重启,故引入两个问题:
- 如果这个服务是有状态的,那么它再次在另外的机器上启动之后,怎么恢复它的状态?Marathon支持本地的持久化卷来解决这个问题
- 如果这个服务之前作为其他服务的后端,或者有外部的客户端和它进行通信,那么当他启动到别的机器上之后,IP地址发生了变化,那么其他服务和外部的客户端改怎么和新的服务进行通信?Marathon支持Service Discovery的方式来解决这个问题
- 提供沙箱机制来管理每个应用的实例
- Rolling Upgrade的支持:即应用程序新版本发布后可以在不中断服务的情况下升级到新版本
- 支持高可用:只需要启动多个Marathon的服务并且指定一个相同的Zookeeper路径,Zookeeper会提供多个Marathon服务之间的Leader选举。并且用户可以在Marathon的非leader节点上操作,而不是像Mesos那样会跳转到leader节点
Marathon-lb
Marathon-lb是个基于HAProxy的快速代理和负载均衡。它能为基于TCP和HTTP协议的应用提供代理和负载均衡,此外还支持SSL、健康检查、HTTP压缩、Lua脚本等特性。Marathon-lb通过Marathon的EventBus可以自动获取Marathon上每个应用的信息,并且能够为每组应用生成HAProxy配置。不同于通过域名机制来发现服务的Mesos-DNS,Marathon-lb是通过servicePort服务端口来发现服务外,另外,还可以通过VHOST来访问服务。
- 问题:Marathon通过一个json配置文件启动两个Nginx服务的instance,此时只生成一个marathon-lb的servicePort?并且通过这一个servicePort可以访问两个Nginx服务吗?
- 只生成一个servicePort,通过这个servicePort可以访问这两个Nginx服务,marathon-lb为这两个Nginx服务生成HAProxy配置,通过HAProxy来实现负载均衡,应用层–http层的负载均衡
Haproxy
四层和七层负载均衡的区别
- 四层负载均衡
- 主要是分析IP和TCP/UDP流量实现的基于IP加端口的负载均衡。常见的四层负载均衡优LVS和F5。
- 以TCP请求为例。客户端将SYN请求发送到负载均衡器,负载均衡器会根据一个负载均衡算法选择一个合适的后端服务器,并修改SYN请求的目标地址,将SYN请求转发到相应的后端服务器。此过程可以看出客户端和服务器之间是直接建立TCP连接的,而负载均衡器相当于实现了路由器的路由转发功能;在转发报文的时候,还可修改报文的目标地址,服务器返回的报文可以正确的传递黑负载均衡器。
- 七层负载均衡
- 也称七层交换机(内容交换器)。主要是根据应用层的诸如HTTP、FTP、SMTP等协议的报文内容,配合负载均衡算法来选择后端服务器。比如对Web服务器的负载均衡,不但可以通过IP+端口的方式进行负载均衡,还可以通过URL、域名、浏览器类别或者语言等进行负载均衡。比如可以实现不同域名访问不同的网站的功能。常见的七层负载均衡器有HAProxy、Nginx等。
- 以TCP请求为例。客户端向七层负载均衡器发送SYN请求,由于此时还未建立TCP连接,客户端还未发送应用层请求报文,负载均衡器则代替后端服务器与客户端建立TCP连接。然后客户端将请求报文发送给负载均衡器,后者根据报文的内容采用负载均衡算法选择一个合适的后端服务器,并与该后端服务器建立TCP连接。在这个过程中,负载均衡器相当于一个代理服务器。
部署DC环境
Shiro登录验证流程
Shiro登录验证的实现和验证流程
实现登录验证
核心类
需要ShiroConfiguration:在这个类中主要是注入shiro的filterFactoryBean和securityManager等对象。
需要StatelessAccessControlFilter:这个类中实现访问控制过滤,当我们访问url的时候,这个类中的两个方法会进行拦截处理。
需要StatelessAuthorizingRealm:这个类中主要是身份认证,验证信息是否合理,是否有角色和权限信息。
需要StatelessAuthenticationToken:在shiro中有一个我们常用的UsernamePasswordToken,因为我们需要这里需要自定义一些属性值,比如:消息摘要,参数Map。
需要StatelessDefaultSubjectFactory:由于我们编写的是无状态的,每人情况是会创建session对象的,那么我们需要修改createSubject关闭session的创建。
需要HmacSHA256Utils:Java 加密解密之消息摘要算法,对我们的参数信息进行处理。
Controller处理web请求的流程
Dispatcher Servlet是怎样被调用的?
我的这篇博客有讲到过程,再来分析一下Spring4.2.6的源代码
DispatcherServlet类继承关系是DispatcherServlet -> FrameworkServlet -> HttpServletBean -> HttpServlet,由DispatcherServlet负责处理Http请求。
另:Shiro里面的securitymanager的作用跟DispatcherServlet的作用很相似,都是负责全局组件交互的前端控制器。
经典算法
A* Algorithm
该算法是一个求最短路径的算法,同Dijkstra算法类似,起始点到终点的距离f(M) = g(M) + h(M),g(M)表示从起始点S走到M点的距离,h(M)表示从M点到终点的估计距离。算法的关键在h的估计上,可以采用欧氏距离、曼哈顿距离等距离度量方式。在采用特定的距离度量方式估计h(M)的值后,计算f(M)的值,并对f(M)的值进行排序,找到最小的f(M)对应的那个节点作为下一个节点。
与Dijkstra算法不同的是,Dijkstra算法是从未走过的节点中找到一个距离已走过的节点最近的节点作为下一个节点,如果A*算法不对f(M)进行排序,则跟Dijkstra算法类似,只是比Dijkstra多计算一个估计值。如果h=0,则A*算法类似于BFS算法,即不考虑终点,只考虑起始点,但可以保证给出最优解;如果g=0,s则A*算法类似于DFS,即不考虑起始点,一根筋的找离终点最近的下一个节点走,这样可能不会给出最优解。
Fibonacci堆
- Fibonacci堆采用双向循环链表;
- 去除最小节点后,将该节点的所有子节点都串联到根表中,然后将根表中度数相同的子树合并,直至没有度数相同的子树。
- 在合并根表中相同度数的子树时,注意孩子节点的值要比父节点的值要小,这样才能保证Fibonacci堆中的最小值始终在根节点上。
- 节点值减小:如果破坏了最小堆性质,则需要重新维护最小堆。首先将值减小的节点及其子树从堆中拿出来,然后将其并到根链表中;然后再从”被切节点的父节点”到所在树根节点递归执行级联剪枝。
- 节点值增大:将值增大的节点的孩子添加到根链表中,如果值增大的节点不在根链表中,则将其也加入根链表中。然后对其父节点进行级联剪切;如果没有父节点,则判断是否需要更新堆得最小值。
- 级联剪切的真正目的是为了防止”最小堆”由二叉树演化成链表。
spring-boot热部署
spring-boot热部署
第一种方式
在pom文件中的plugin下添加:1
2
3
4
5
6
7<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>springloaded</artifactId>
<version>1.2.6.RELEASE</version>
</dependency>
</dependencies>第二种方式
直接在pom文件中引入依赖:1
2
3
4
5<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools/artifactId>
<optional>true</optional>
</dependency>
hexo搭建个人博客并保存环境
hexo搭建个人博客并保存环境
搭建过程可以参考网上一篇教程:Mac上搭建hexo
按照以上博客的配置,即可将个人博客搭建好,如果你想要将博客的环境保存下来,下次换台机器后还能继续使用之前配置的环境的话,可以在blog文件夹下新建一个git仓库(git init),将该仓库托管到github上的某一个仓库里(我是将blog文件夹下的全部文件托管在github中博客所在仓库的hexo分支上),每次重新搭建环境的时候只需要从该分支拉取下来所有的环境信息即可在原来的基础上开始写新的博客。
在执行完:node install -g hexo
后,不要执行hexo init
,进入到blog文件夹,执行git init
,创建git仓库,执行git remote add origin git@github.com:konnase/konnase.github.io.git
添加原来的环境所在的远程git仓库,执行git pull origin hexo:master
将远程的仓库拉取到本地,执行npm install
安装hexo相关环境。到此,即可无缝使用原来的hexo环境了。
next主题的_config.yml文件复制到source/_data/next.yml,方便保存配置信息,因为next主题我是不会提交到git仓库中去保存的。
next主题使用latex
1 | sudo npm uninstall hexo-renderer-marked |
修改node_modules/kramed/lib/rules/inline.js下面的两行:
1 | var inline = { |