本文将对卡尔曼滤波做一个粗略总结~
假定一个机器人导航，其状态用$\vec{x_k}$描述：
采用一个向量描述状态：
两个假设：
我们考虑速度和位置是有关联的：
矩阵描述问题
协方差用于衡量p和v两个变量的总体误差，
状态迁移描述：
其中的预测过程用一个矩阵描述Fk：
我们预测速度和位置的迁移公式：
预测矩阵描述：
虽然有了预测矩阵，但是我们还不知道如何更新协方差矩阵；
这样我们用下面的方法更新协方差矩阵：
注意这里是大写的P，代表概率，协方差概率；
该文分析了API安全相关的验证与鉴权技术特点与基本原理。
前端与权限
微服务中的身份
API gateway
如何解决前端与API消费者同时鉴权问题
RDBC
JWT1
jwt2
ominiplan_tool
线程安全是多线程程序中的编程理念，一段代码线程安全意味着在多个线程执行的时候能够运行正确。因此，它必须满足：
rel="nofollow"属性以避免受到攻击；OAuth2 and OpenID Connect
Securing each step of the request’s journey
favicon.ico文件, 比如. /favicon.ico。浏览器会自动请求该文件，甚至在HTML中无需提及；如果没有这样的文件/favicon.ico，会产生多个404错误，消耗网站带宽；example.com/pages/45-article-title 而不是example.com/index.php?page=45； #替换诶#！； click here的链接；/sitemap.xml；<link rel="canonical" ... />；我们主要关注ConnectionSocketFactory，用于创建和连接socket，
可以实现为非加密socket:
|
|
也可以实现为加密socket;
也可以继续扩展增加新的方法：
|
|
将基于HttpURLConnection类的HTTPClient修改为HttpClient4.3.2：
在httpClient中可以自定义连接重用的策略，定义了一个接口类ConnectionReuseStrategy：
|
|
其缺省的实现类为org.apache.http.impl.DefaultConnectionReuseStrategy:
其中该类似实现了接口类的对外方法keepAlive。当然我们可以自定义一个连接重用策略：
调用者为org.apache.http.impl.execchain.MainClientExec：
连接关闭的调用条件：
其中内部实现如下：
SSLConnectionSocketFactory类可以基于SSLSocketFactory、支持的协议、支持的密码套件进行构造：
其中supportCipherSuites作为自定义密码套件在握手过程中检查。
本文由skypacer译自Patterns in C REACTOR，原文作者Adam Petersen。
本篇英文原文所发布的站点Adam Petersen是一个个人网站，本文翻译了其中reactor C实现章节, 水平有限，欢迎指正。
1、多客户端示例
2、单一责任原则
3、违反Open-Closed原则
4、从性能谈起
5、问题总结
6、REACTOR模式
6.1、事件探测
6.2、实现机制
6.3、Reactor注册策略
6.4、Reactor实现
6.5、触发Reactor
6.6、处理注册
6.7、事件多样性
7、REACTOR vs OBSERVER
8、结论
9、总结
本文将研究一种适用于event-driven应用的模式。Reactor Pattern将应用的不同职责解耦，允许应用由多个潜在的client端分离并分发事件。
我们可以以单位时间内的操作次数定义性能，比如每秒请求数，每秒交易数；
可扩展性： 指通过增加计算资源以提高处理负载的能力，分为水平扩展和垂直扩展；
对于垂直扩展，我们针对单一机器本身，比如用SSD替换HDD，换个更快的CPU等，往往效果有限；
而水平扩展则不然，我们通过增加更多服务器将性能提升至几十倍上千倍，但同时难度也更大，需要确保数据的一致性；
对于WEB服务，如果我们只是单纯增加服务器数量，数据库势必很快将成为瓶颈，因此我们引入cache；
注：这里的数据库一般指传统的关系型数据库，支持用于完成业务逻辑的SQL；
Cache的几个概念：
“多久更新，如何更新”
从调用者与cache的交互方式上，我们可以分为三大类：
作为用户访问云服务的重要手段，SDK往往充当了proxy的角色，其内部加入L2 cache，可有效降低对服务本身的访问压力；
从架构上划分，cache可分为本地与分布式；
当然其缺点也很明显，首先本次缓存与程序紧耦合，多个应用程序无法共享缓存，各应用和集群节点都必须维护自己的单独缓存，也是一种浪费；另外，为了保证多个进程间的数据一致性，程序相对不易维护；
其中Ehcache的缓存数据有两级：内存和磁盘，与一般的本地内存缓存相比，有了磁盘的存储空间，将可以支持更大量的数据缓存需求；
直接实现
a. 成员变量或局部变量实现
|
|
以局部变量map结构缓存部分业务数据，减少频繁的重复数据库I/O操作。缺点仅限于类的自身作用域内，类间无法共享缓存。
b. 静态变量实现
最常用的单例实现静态资源缓存，代码示例如下：
|
|
O2O业务中常用的城市基础基本信息判断，通过静态变量一次获取缓存内存中，减少频繁的I/O读取，静态变量实现类间可共享，进程内可共享，缓存的实时性稍差。为了解决本地缓存数据的实时性问题，目前大量使用的是结合ZooKeeper的自动发现机制，实时变更本地静态变量缓存：
TODO:实际项目：相对静态数据，比如元数据可以基于本次cache加速，
美团点评内部的基础配置组件MtConfig，采用的就是类似原理，使用静态变量缓存，结合ZooKeeper的统一管理，做到自动动态更新缓存，如图2所示。
美团
TODO1：根据期望到货时间排序通知，需要考虑加入本地cache, EBOOK – REDIS IN ACTION
TODO2: Pub/Sub：在更新中保持用户对数据的映射是系统中的一个普遍任务。Redis的pub/sub功能使用了SUBSCRIBE、UNSUBSCRIBE和PUBLISH命令，让这个变得更加容易。到货通知
Java Cache Benchmark
sping cache
目前的实现memcached、redis和tair;
分布式cache性能对比
redis
Understanding transaction pitfalls
网络爬虫
stakcoveflow架构
Global Cache
网络拓扑同步用到了global cache，流程：
Secure Software and Secure Development Tools
手段：
其中JAVA的静态扫描示例：
Redis基于TCL编写测试框架；
Spring Boot中的缓存支持（一）注解配置与EhCache使用
多数 ide 会提示声明一个静态常量 serialVersionUID(版本标识), 类已经序列化，serialVersionUID是JAVA的序列化过程中用于标识和识别序列化类的；
Serializable 则是应用于Java 对象序列化/反序列化, 作用：
框架实现：
调用过程分析：
|
|
其中cache执行器CacheingExecutor, 如果配置了使用cache的标志(在mapper.xml中)，直接从cache中获取;
用途：解耦调用方和被调用方
TODO：
在一些文献中关于 reactor 的描述中，定义了一个工具，即 synchronous Event Demultiplexer ， 该分离器由 reactor 调用等待已经注册的 Handles 的事件。
该事件分离器一般由操作系统提供，比如 poll() ，select() 和 WaitForMutipleObjects() 。
EventHandler 和 Reactor 之间的合作关系类似OBSERVER模式中的observer和它的对象。
为了将Reactor和它的事件处理器解耦，同时Reactor仍能够通知到他们，每个具体的事件处理器必须关联一个唯一的instance。这里的C实现中，采用void 作为通用类型以描述 *EventHandler 接口。
|
|
应用REACTOR模式的主要结论如下：
对于类似订单中心的多Key类业务，在数据量较大，需要对数据库进行水平切分时，对于后台需求，采用“前台后台分离”的架构设计方法：
|
|
Reactor模式通过对不同责任的解耦和不同模块的封装简化了事件驱动型应用的设计。关于该模式更多的讨论可以参考面向对象的软件模式卷2。
生产者-消费者模式即所谓的Fan-in设计模式，这里建立两个channel，一个由多个生产者将生产的数据写入；另外一个由一个消费者读出。
线程同步由主线程借助两个channel完成，其本质是利用了阻塞实现同步。
一个大loop将每个新的i值循环写入。
|
|
|
|
从写入channel rang loop的读取，塞入输出channel。
|
|
这里利用了阻塞channel的特性：如果读取不到则阻塞，可以加入超时。
现象：
|
|
将生产者的loop变成有限次执行后退出。
|
|
将会导致main线程和reader线程阻塞:
|
|
|
|
|
|
将消费者行为改为对数据不做消费：
|
|
导致多个线程都往channel中写数据，这里channel是不一致的（可以一致）：
|
|
|
|
out无人消费，导致写了一个就已经满了，因此阻塞。
|
|
发现ch数据没有被消费，写不进去而阻塞。
Close行为与loop之间通过s.closing
|
|
通过一个channel发送消息给待关闭的thread，将channel类型设置为channel，这样loop可以将错误的原因发送过来:
|
|
Loop的处理：取走error并退出
|
|
对于nil channel，无论发送与接收操作都会阻塞；
select永远不会选择一个阻塞的case.
nil channel与空channle的区别：？
|
|
获取goroutine的GID：
|
|
|
|
这里用到了C++11的新特性——可调用对象模板类，可调用对象理解为函数，该特性可以用于定义函数指针，相当于是把函数本身做进一步抽象。这里利用该特性定义了三个回调函数，以第一个typedef boost::function<bool (const TcpConnectionPtr&, StringPiece，Timestamp)> RawMessageCallback为例：
function<bool (const TcpConnectionPtr&, StringPiece，Timestamp)>意思是定义了一个可调用对象（函数指针），参数是三个const TcpConnectionPtr&, StringPiece，Timestamp。RawMessageCallback，或者说是一个可调用对象。该上下文的调用如下：
|
|
可以结合map容器和该特性定义一张函数表，如下示例：
|
|
运行结果如下：
|
|
这里面有几个坑要注意：
auto mod = [ ](int i, int j)定义了一个lamba表达式，即没有函数名的函数，这是什么鬼？注意函数实现最后有分号；#include <stdexcept>；#include <typeinfo>，然后直接typeid(var)即可。从运行结果可以看到迭代器本身的类型和迭代器成员的类型区别。->操作符。TODO: 容器遍历与访问的两种方法：迭代器和容器内部方法之区别。
该文摘自What technical details should a programmer of a web application consider before making the site public?，实际上列出了Web安全的知识体系，也包括了工程开发当中的指导准则。
线程安全是多线程程序中的编程理念，一段代码线程安全意味着在多个线程执行的时候能够运行正确。因此，它必须满足：
rel="nofollow"属性以避免受到攻击；favicon.ico文件, 比如. /favicon.ico。浏览器会自动请求该文件，甚至在HTML中无需提及；如果没有这样的文件/favicon.ico，会产生多个404错误，消耗网站带宽；example.com/pages/45-article-title 而不是example.com/index.php?page=45； #替换诶#！； click here的链接；/sitemap.xml；<link rel="canonical" ... />；线程安全是多线程程序中的编程理念，一段代码线程安全意味着在多个线程执行的时候能够运行正确。因此，它必须满足：
保证的手段如下：
一个任务执行该代码的一部分，此时另外一个任务进来，最后再恢复到原先任务。这就需要保存每一个任务的本地局部变量，一般保证在自己的栈当中，而不是static或者全局变量。
如果采用某种机制使得序列化访问共享数据，保证在任意时刻只有一个线程读写数据。由此引发条件竞争、死锁、活锁、饥饿等问题。
使用静态数据或任何其他共享资源的函数（比如文件或终端）必须通过锁使得对这些资源的访问串行化，以便函数变为线程安全。例如，以下函数是线程不安全的：
|
|
要使其变为线程安全的，那么必须通过静态锁将静态变量 counter 保护起来，如以下例子所示：
|
|
在使用线程库的多线程应用程序中，应使用 mutex 来对共享资源进行串行化。独立的库可能需要在线程的上下文以外工作，因此，请使用其他种类的锁。
其实就是变量本地化，即确保每个thread拥有自己的私有拷贝。
|
|
采用原子操作保证其他thread无法中断当前操作，通常通过特殊的机器指令，比如xchag和TSL。原子操作构成了多线程锁机制的基础。
线程安全函数
线程安全函数通过锁来保护并发访问中的共享资源。线程安全只与函数的实现有关，并不会影响它的外部接口。
在C语言中，局部变量是在堆栈中动态分配的。因此，任何不使用静态数据或其他共享资源的函数一般都是线程安全的。
全局数据的使用是线程不安全的。全局数据应针对每个线程保存或被封装起来，这样可以使它的访问串行化。线程可以读取对应于由另一个线程引起的错误的错误代码。
在多线程程序中，所有被多个线程调用的函数必须是线程安全的。但是，对于在多线程程序中使用线程不安全子例程有一个变通方法。虽然非重入函数通常都是线程不安全的，但是将它们变为重入常常也使它们变为线程安全。
使函数成为重入函数
在多数情况下，必须用带有已修改的将要重入的函数来替代非重入函数。非重入函数不能由多个线程使用。此外，可能也无法使非重入函数变为线程安全。
许多非重入函数会返回一个指向静态数据的指针。可以用以下方法来避免这种情况：
|
|
该函数不是重入函数（也不是线程安全的函数）。要通过返回动态分配的数据来使该函数重入，那么该函数应类似于以下代码段：
|
|
较好的解决方案是修改接口。调用程序必须为输入和输出字符串提供存储量，如以下代码段所示：
|
|
使用调用程序提供的存储量使非重入标准 C 库子例程重入。
在连续调用中保存数据
在连续调用中将不保存任何数据，因为不同的线程可能连续地调用该函数。如果函数必须在连续调用中保存某些数据，比如工作缓存或指针，那么调用程序应提供该数据。
如下示例，函数返回了字符串中连续的小写字符。该字符串只在第一次调用时提供，就像strtok子例程。函数在到达字符串的结尾处时返回 0。该函数可通过以下代码段来实现：
|
|
该函数不是重入函数。要使其变为重入函数，那么调用程序必须保存静态数据和变量 index。该函数的重入版本可通过以下代码段来实现：
|
|
该函数的接口和用法都发生了改变。调用程序必须向每次调用提供该字符串，且在首次调用前，必须将索引初始化为 0，如以下代码所示：
|
|
TLS库的线程安全
在TLS实现中，常见的需要保证线程安全的场景主要有：
目前的TLS线程安全由pthread_mutex互斥锁保证。
编写重入和线程安全代码
在单线程进程中，只存在一个控制流。因此，这些进程所执行的代码无需重入或是线程安全的。在多线程程序中，相同的功能和资源可以通过多个控制流并发访问。
要保护资源的完整性，编写的多线程程序代码必须能重入并是线程安全的。重入和线程安全都与函数处理资源的方式相关。重入和线程安全是不同的概念：函数可以重入和/或线程安全化，或者两者都不可行。
此部分提供了有关编写重入和线程安全程序的信息。其中不涉及有关编写高效线程程序的主题。高效线程程序是高效率的并行化程序。您必须在设计程序的时候考虑到线程的效率。现有的单线程程序可以成为高效线程程序，但是这需要将这些程序完全重新设计和重新编写。
除了上述方法，可以有变通方法编写：
该变通方法很有用，尤其是在使用多线程程序中的线程不安全库进行测试时，或者同时在等待线程安全的库变成可用时。该变通方法会导致一些开销，因为它是通过对整个函数，甚至一组函数进行串行化来实现的。以下是可能的变通方法：
|
|
|
|
重入函数不在连续的调用中保存静态数据，也不返回指向静态数据的指针。所有的数据都是由函数的调用程序提供的。重入函数不得调用非重入函数。
一般情况下，非重入函数是由其外部接口和用法标识的，但也并不总是这样。例如，strtok 子例程不是一个重入函数，因为它保存了将分割为多个标记的字符串。ctime 子例程同样不是重入函数；它返回了被每个调用所覆盖的静态数据的指针。
重入库和线程安全库并不仅仅在线程中有用，而且在大范围的并行（和异步）编程环境中也很有用。一直使用和编写重入函数和线程安全函数是很好的编程实践。
使用库
标准C库 (libc.a)和Berkeley兼容性库(libbsd.a)以下库是线程安全的，有些标准 C 子例程是非重入的，比如 ctime 和 strtok 子例程。
在编写多线程程序的时候，请使用子例程的重入版本来替代原来的版本。例如，以下代码段：
|
|
在多线程程序中应使用以下代码段来代替：
|
|
在一个程序中，线程不安全的库可能只由一个线程使用。请确保使用该库的线程的唯一性；否则，程序可出现意外的行为，甚至可能停止。
转换库
在将一个现有的库转换为重入库和线程安全库的时候，请考虑以下问题。此信息只适用于 C 语言库。
最近将工作中碰到的一个问题记录下，以备查找。该问题的现象是程序在连接某一个APP时失败，日志显示TCP读超时，但是连接其他APP都成功。
初步调试发现，此时client与server已经建立SSL连接，但是在读取APP数据时select超时，但为什么单单在连接这个APP的时候出现超时呢？
首先看SSL连接的建立过程，如图1所示：
注：
而SSL本身的数据处理如图2所示：
让我们回到数据读取，这里需要说明的是程序采用的事件处理框架。作为SSL客户端，为了能够处理多个SSL连接建立后对多个socket的并发事件处理，引入了select机制，事实上最多支持32个SSL连接。Select作为一种非阻塞IO接口，在这里用于轮询建立的TCP socket (SSL连接基于TCP socket，当然例外情况是DTLS基于UDP) 事件，结果发现没有数据可读。
数据读取在非阻塞模式下遵从能读多少就读多少的原则，同理数据写入在非阻塞模式下也遵从能输出多少就输出多少的原则,其中输出缓冲区如下图所示：
进一步查看已经建立的SSL连接表，结构如图2所示。SSL连接表本身由一个数组存储，为了加快SSL连接的查找又引入了一张哈希表，该哈希表采用数组作为散列的桶，每个桶是一个单向链表以解决哈希冲突。
当前的SSL连接表显示多个SSL连接都挂在了一个桶的链表上，看起来是发生了哈希冲突，但细想这概率似乎有点高，那就看看为啥这几个SSL连接都搞出来一个key， 注意到这里的hash key是TCP socket的抽象数据结构指针，再看代码直接把当前进程中的文件描述作为查找键，增加一行代码就好了，即利用getsock拿到真正的socket数据结构指针。
为了搞清楚错误是怎么发生的，有必要来个情景再现。让我们看看在哈希表插入的时候发生什么。哈希表的插入发生在新建一个SSL连接的时候（每一个SSL连接对应一个TCP socket），当TCP连接建立之后，SSL就以socket作为key插入哈希表当中。由于APP在SSL建立时候打开的一个文件描述符和隧道建立时候打开的文件描述符一些情况下是一样的，这样新旧两个SSL连接描述符产生相同的key,都插入同一个桶，对应依次插入链表尾部，当进行数据读写时根据文件描述符查找到的是旧的SSL连接描述符，此时该连接符已无数据可读写，导致超时。
服务器端证书用于标识一个Server，典型地被签发给主机名，比如机器名或者host-header(www.baidu.com)。对Server证书而言，”Issued to”域意味着选择哪个签发的hostname。
服务器端证书用于标识一个Client或者user，意味着向Server验证Client，”Issued to”域采用用户的名字。
在HTTP下有虚拟主机这一概念，其目的是为了在服务端用单个IP支持多个主机名；对应到HTTPS，客户端验证服务器为不同主机配置多个证书，但是客户端需要检查服务器证书的common name,当客户端请求服务器证书的时候，服务器需要决定提供哪个证书，SNI应用而生，其原理如下图：
SSL中间人攻击的形式主要有三种：SSL downgrading，SSL stripping和fake of SSL certs。
在SSL协议中，证书是用来进行身份验证的，这里有两个关键的检查点：
缺失模块。
1、请确保node版本大于6.2
2、在博客根目录（注意不是yilia根目录）执行以下命令：
npm i hexo-generator-json-content --save
3、在根目录_config.yml里添加配置：
jsonContent:
meta: false
pages: false
posts:
title: true
date: true
path: true
text: false
raw: false
content: false
slug: false
updated: false
comments: false
link: false
permalink: false
excerpt: false
categories: false
tags: true