个人博客

1.引子 http的无状态 http的无状态，第一次访问和第二次访问是完全独立的，需要将不同的请求的行为串起来，那就让服务器和浏览器共同维护一个状态吧！这就是会话机制。（浏览器第一次请求服务器，服务器创建一个会话，并将会话的id作为响应的一部分发送给浏览器，浏览器存储会话id，并在后续第二次和第三次请求中带上会话id，服务器取得请求中的会话id就知道是不是同一个用户了，这个过程用下图说明，后续请求与第一次请求产生了关联） 服务器在内存中保存会话对象，浏览器怎么保存会话id呢？你可能会想到两种方式 请求参数 cookie 将会话id作为每一个请求的参数，服务器接收请求自然能解析参数获得会话id，并借此判断是否来自同一会话，很明显，这种方式不靠谱。那就浏览器自己来维护这个会话id吧，每次发送http请求时浏览器自动发送会话id，cookie机制正好用来做这件事。cookie是浏览器用来存储少量数据的一种机制，数据以”key/value“形式存储，浏览器发送http请求时自动附带cookie信息 tomcat会话机制当然也实现了cookie，访问tomcat服务器时，浏览器中可以看到一个名为“JSESSIONID”的cookie，这就是tomcat会话机制维护的会话id，使用了cookie的请求响应过程如下图： 单系统登录解决方案的核心是cookie，cookie携带会话id（sessionId）在浏览器与服务器之间维护会话状态。但cookie是有限制的，这个限制就是cookie的域（通常对应网站的域名），浏览器发送http请求时会自动携带与该域匹配的cookie，而不是所有cookie 既然这样，为什么不将web应用群中所有子系统的域名统一在一个顶级域名下，例如“*.baidu.com”，然后将它们的cookie域设置为“baidu.com”，这种做法理论上是可以的，甚至早期很多多系统登录就采用这种同域名共享cookie的方式。 然而，可行并不代表好，共享cookie的方式存在众多局限。首先，应用群域名得统一；其次，应用群各系统使用的技术（至少是web服务器）要相同，不然cookie的key值（tomcat为JSESSIONID）不同，无法维持会话，共享cookie的方式是无法实现跨语言技术平台登录的，比如java、php、.net系统之间；第三，cookie本身不安全。 共享 Cookie 的应用系统必须协商并统一使用相同的 Cookie 名称来标识用户会话。不能tomcat教JSESSIONID。php又叫xxxxx。或者用更安全和可行的方法是使用标准的身份验证和授权协议，如OAuth或OpenID Connect。这些协议定义了一致的方式来处理用户身份验证和会话管理，而不依赖于特定的 Cookie 名称。 传统验证用户信息用的是session和cookie这种组合，session存在服务器上，cookie存在客户端。cookie由服务器生成的，发给客户端存着，客户端每次请求就会携带cookie，服务器就会通过cookie的内容从而识别客户端的身份。session存在服务器，客户端的请求都会携带自己的身份信息，服务器就会通过session对比这个信息判断请求是否合法。但是session用户过多开销过大，也不能在多个服务器的服务端下使用，因为它存在服务器的内存中无法共享。 2. 会话机制 过程： 1 服务端生成sessionId存储并返回 2 客户端的each 请求默认传cookie(里面塞了sessionId) 缺点： 1 cookie无法解决 跨域、跨语言平台的问题（cookie有限制，不能跨域，只能发送域下匹配的所有cookie），因为cookie是跟浏览器以及各自的语言框架耦合集成的 ​ 2 服务端需要存储，传统的session存在服务器内存中、redis中，浪费内存https://zhuanlan.zhihu.com/p/135247813 前面已经回答的挺透彻的了，补充一点概念辨析权当拾遗。 SSO本质上属于一种需求。 CAS（中央认证服务）本质上是一个框架，用于实现SSO的需求，但是并不提供具体的解决方案，只是规定了CAS Server和CAS Client的关系，其中中央认证服务器必须单点部署，而其他可以分布部署。 OAuth2是一个协议，用于解决CAS框架下，客户资源安全的问题。通过中央认证服务器提供的Token来保证用户资源不会被窃取。同样SAML也是一个协议。 JWT是一种具体的技术实现方案，通过在请求头部置入一个加密后的多段式Json（一般至少是三段：header, payload, signature）来保证token的可靠性。 3.单点登录（SSO） 简述： N个系统 只要其中1个登录，其他系统不需要重复认证登录了 单点登录四大主流协议： CAS、OAuth、OpenID Connect、SAML方案 单点登录有很多实现方案，最主流的还是基于CAS的方案。设计一套支持单点登录的鉴权认证系统，所有系统都基于一套鉴权系统进行登录，并且可以实现各个系统之间的互信和跳转。CAS架构的核心是需要搭建一个CAS Server，该服务独立部署，拥有独立三级域名，主要负责对用户的认证工作。他主要组成包括WEB前端提供登录页面，票据模块，认证模块。 在 B/S 系统中，登录功能通常都是基于 Cookie 来实现的。当用户登录成功后，一般会将登录状态记录到 Session 中，或者是给用户签发一个 Token，无论哪一种方式，都需要在客户端保存一些信息（Session ID 或 Token ），并要求客户端在之后的每次请求中携带它们。在这样的场景下，使用 Cookie 无疑是最方便的，因此我们一般都会将 Session 的 ID 或 Token 保存到 Cookie 中，当服务端收到请求后，通过验证 Cookie 中的信息来判断用户是否登录 。 单点登录（Single Sign On, SSO）是指在同一帐号平台下的多个应用系统中，用户只需登录一次，即可访问所有相互信任的应用系统。举例来说，百度贴吧和百度地图是百度公司旗下的两个不同的应用系统，如果用户在百度贴吧登录过之后，当他访问百度地图时无需再次登录，那么就说明百度贴吧和百度地图之间实现了单点登录。 单点登录的本质就是在多个应用系统中共享登录状态。如果用户的登录状态是记录在 Session 中的，要实现共享登录状态，就要先共享 Session，比如可以将 Session 序列化到 Redis 中，让多个应用系统共享同一个 Redis，直接读取 Redis 来获取 Session。当然仅此是不够的，因为不同的应用系统有着不同的域名，尽管 Session 共享了，但是由于 Session ID 是往往保存在浏览器 Cookie 中的，因此存在作用域的限制，无法跨域名传递，也就是说当用户在 http://app1.

1. 介绍 git下载、hugo下载 go写的，场景：适合 海量时许数据的插入和查询的场景（ 注意：删除和更新 支持很少） 监控告警 iot物联网设备数据采集 官方有OSS单机开源版、官方集群版闭源收费，走商业路线。 主流版本有1.X 和 2.X 1.X以1.8为主流 InfluxDB 2.0 正式版本，该版本又分为两个系列，云模式的 InfluxDB Cloud 和独立部署的 InfluxDB OSS 2.x的区别 1整合了TICK 四个组件，分别对应Telegraf数据采集，InfluxDB数据存储，Chronograf WebUI数据可视化，Kapacitor 告警 权限增强，支持token读写数据 增加查询语言 Flux语法 性能 影响因素 本身机器硬件参数（32G内存 16核CPU标准版） 数据量、网络带宽 influxdb版本 1.8.10、mearsurement个数、field个数、tag个数 举例来说，基本的服务器配置 32G内存 16核，支持每s几W的写入 没什么问题，正常的查询在1-20ms之内 网上测试参考 8G内存 2核cpu 最大的吞吐量为每秒写入60万条数据（3个字段，1个索引） 读取性能 2ms/条 环卫云项目参考 32G 16核cpu 1000Mbps的带宽 平均吃 8G内存 600% cpu 每秒写入 2-3K条数据（50个字段、2-3个索引） 功能性 HTTP协议的API 通过数据库本身的聚合函数 retention policy：数据存储策略（默认策略为autogen）InfluxDB没有删除数据操作，规定数据的保留时间达到清除数据的目的 底层时间戳为纳秒， 存储用的是utc时间戳（自1970年1月1日起的相对时间戳），支持通过 tz（Asia/China）转化成对应时区的时间 横向对比 在时序数据库出现之前，存储时序数据这项领域一直被 MongoDB 所占据，在数据量不够高的情况下，InfluxDB 并不会比 MongoDB 或者 ElasticSearch 有更明显的优势 MySQL、Oracle 等，优点是具有 ACID 的特性，各方面能力都比较均衡。缺点是查询、插入和修改的性能都很一般。 基于 PostgreSQL 的 TimeScaleDB 高性能写入、高性能查询、低存储成本、支持海量时间线、弹性 纵向对比

Step 1. 准备条件 git下载 hugo下载 Step 2. 搭建过程 环境准备 下载hugo window版本 配置环境变量到Path 创建hugo项目 （zml_blog） hugo new site zml_blog cd zml_blog git init git拉取某个选定的theme皮肤 这里选定blackburn（参考博客和UI） git submodule add git@github.com:yoshiharuyamashita/blackburn.git themes/blackburn theme文件复制并替换 除了git.ignore外 把D:\2 work software\hugo\my_blog\zml_blog\themes\blackburn下 文件复制到根目录 zml_blog下并替换 复制theme的配置文件 把config文件 D:\2 work software\hugo\my_blog\zml_blog\themes\blackburn\exampleSite内容 复制到D:\2 work software\hugo\my_blog\zml_blog\content下 注意最终生效的配置文件为hugo.toml 复制theme配置页面 把page文件 D:\2 work software\hugo\my_blog\zml_blog\themes\blackburn\exampleSite\content内容 复制到toml.config 重新运行 hugo server 编译生成public并上传到git D:\2 work software\hugo\my_blog\zml_blog\public下文件 复制到D:\2 work software\hugo\my_blog\git_pages\zgjsdtzml.github.io下 git add. git commit -m 'xxx' git push add/update博客文章

Introduction This tutorial will show you how to create a simple theme in Hugo. I assume that you are familiar with HTML, the bash command line, and that you are comfortable using Markdown to format content. I’ll explain how Hugo uses templates and how you can organize your templates to create a theme. I won’t cover using CSS to style your theme. We’ll start with creating a new site with a very basic template.

Move static content to static Jekyll has a rule that any directory not starting with _ will be copied as-is to the _site output. Hugo keeps all static content under static. You should therefore move it all there. With Jekyll, something that looked like ▾ <root>/ ▾ images/ logo.png should become ▾ <root>/ ▾ static/ ▾ images/ logo.png Additionally, you’ll want any files that should reside at the root (such as CNAME) to be moved to static.

Hugo uses the excellent go html/template library for its template engine. It is an extremely lightweight engine that provides a very small amount of logic. In our experience that it is just the right amount of logic to be able to create a good static website. If you have used other template systems from different languages or frameworks you will find a lot of similarities in go templates. This document is a brief primer on using go templates.

Step 1. Install Hugo Goto hugo releases and download the appropriate version for your os and architecture. Save it somewhere specific as we will be using it in the next step. More complete instructions are available at installing hugo Step 2. Build the Docs Hugo has its own example site which happens to also be the documentation site you are reading right now. Follow the following steps: Clone the hugo repository Go into the repo Run hugo in server mode and build the docs Open your browser to http://localhost:1313 Corresponding pseudo commands: