关于radius认证和portal认证服务器的一点问题，因为最近接触到这方面的配置有一点疑惑，现在把我理解的说下，麻烦各位大神看看理解的对不
首先，我最主要的问题是关于portal认证时，需要有radius认证服务器和portal认证服务器同时存在，我不理解的就是radius服务器就是拿来验证用户名和密码的，那么portal服务器是用来做什么的？
首先说最简单的情况，只有radius认证的情况：
这个时候用户名发送用户名和密码到radius client，在radius
client上会有相应的配置，配置和radius
server上相同的密钥，这样保证在传输用户名和密码时对用户名和密码进行加密，可能还有对radius
client进行认证的功能吧，这里就不多说了
互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成（Continuous
integration，简称CI）。
本文简要介绍持续集成的概念和做法。
持续集成指的是，频繁地（一天多次）将代码集成到主干。
它的好处主要有两个。
（1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
（2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
Martin
Fowler说过，"持续集成并不能消除Bug，而是让它们非常容易发现和改正。"
与持续集成相关的，还有两个概念，分别是持续交付和持续部署。
Jenkins 是一个可扩展的持续集成引擎。
主要用于：
UEBA: User and Entity Behavior Analytics
作为一种高级网络安全威胁检测手段，用户实体行为分析（UEBA）这个网络安全市场的新成员，这两年一直备受关注。我们来看一下市场分析定位，就能感受到用户实体行为分析（UEBA）的发展速度了。
能够高准确率命中异常事件，使真正的安全威胁浮出水面，这正是用户实体行为分析（UEBA）备受关注的主要原因。但是，用户实体行为分析（UEBA）技术复杂，实施部署难度大、成本高，企业应用失败的案例也比比皆是。为此，笔者将自己对用户实体行为分析（UEBA）的理解，以及在实施落地过程中的关键事项进行一下总结，希望能够给大家一些可供参考的信息。
以太坊是一个全新开放的区块链平台，它允许任何人在平台中建立和使用通过区块链技术运行的去中心化应用。就像比特币一样，以太坊不受任何人控制，也不归任何人所有——它是一个开放源代码项目，由全球范围内的很多人共同创建。和比特币协议有所不同的是，以太坊的设计十分灵活，极具适应性。在以太坊平台上创立新的应用十分简便，随着Homestead的发布，任何人都可以安全地使用该平台上的应用。
LUN的全称是Logical Unit
Number，也就是逻辑单元号，其主要作用是为了给相连的服务器分配 逻辑单元号(LUN)。磁盘阵列上的硬盘组成RAID组后，通常连接磁盘阵列的服务器并不能直接访问RAID组，而是要再划分为逻辑单元才能分配给服务器。这是因为SCSI总线上可挂接的设备数量是有限的，一般为8个或者16个，我们可以用Target
ID(也有称为SCSI
ID的)来描述这些设备，设备只要一加入系统，就有一个代号，在区别设备的时候,只要说几号几号就可以了。而实际上需要用来描述的对象，是远远超过该数字的，于是引进了LUN的概念，也就是说LUN
ID的作用就是扩充了Target ID。每个Target下都可以有多个LUN
Device，通常简称LUN
Device为LUN，这样就可以说每个设备的描述就由原来的Target x变成Target x
LUN
y了。LUN就是我们为了使用和描述更多设备及对象而引进的一个方法而已，一点也没什么特别的地方。
LUN
ID不等于某个设备，只是个号码而已，不代表任何实体属性，在我们的实际环境里，我们碰到的LUN可能是磁盘空间，可能是磁带机，或者是media
changer等等。
物理CPU就是计算机上实际配置的CPU个数。在linux上可以打开cat /proc/cpuinfo 来查看，其中的physical id就是每个物理CPU的ID，你能找到几个physical id就代表你的计算机实际有几个CPU。在linux下可以通过指令 grep ‘physical id’ /proc/cpuinfo | sort -u | wc -l 来查看你的物理CPU个数
核数就是指CPU上集中的处理数据的cpu核心个数，单核指cpu核心数一个，双核则指的是两个。通常每个CPU下的核数都是固定的，比如你的计算机有两个物理CPU，每个CPU是双核，那么计算机就是四核的。linux的cpu核心总数也可以在/proc/cpuinfo里面通过指令cat
/proc/cpuinfo查看的到，其中的core
id指的是每个物理CPU下的cpu核的id，能找到几个core
id就代表你的计算机有几个核心。也可以使用指令cat /proc/cpuinfo | grep
“cpu cores” | wc -l来统计cpu的核心总数。
在IT基础架构领域工作有十年了，亲眼目睹和参与了上一代网络存储架构在中国的兴起和衰败。的确，新IT浪潮已经到来，超融合就是诸多风口之一，成为了近几年IT业界备受关注的话题。虽然超融合这个概念已经被厂商热炒了至少两年，但看到市场上依旧存在着很多模糊的定义和理解，所以想整理一些学习笔记和个人见解，希望这些干货内容能对想入门的朋友有所帮助 。
首先大家需要有一个概念，我们看到的这些名词，事实上都是最早推行这些架构的厂商建立起来的，比如Nutanix最早推广的超融合这个概念（HCI
：Hyper Converge
Infrastructure），目的无非是建立一个产品的品类，这是营销惯常的手法，但老外玩儿的真的很溜很成功。
Nutanix起步的核心技术是分布式存储，只是在部署架构上有了进一步创新，采用了这种融合的方式。其实这种创新在技术本身上并没有大的难度，但很大程度上推进了分布式存储的市场落地。
所以这就是超融合1.0的核心，但市场上很多人，被“融合”二字迷惑，甚至一些厂商，也就顺水推舟，弱化存储部分（弱化的原因是存储真的很难做好），单纯去强调融合，把一堆无关痛痒的东西集成起来。个人觉得这不是正途。
我认为真正撬动传统IT市场的超融合1.0的特征主要是两点：
下面对比中能看到，给用户带来价值的重要特性中，大概70%是来自于分布式存储，30%是超融合架构带来的好处（比如管理简化，使用成本的降低），但恰恰是这30%，让用户更愿意从传统架构切换到分布式架构上来。
HomeKit，是苹果2014年发布的智能家居平台。2015年5月15日，苹果宣布，首批支持其HomeKit平台的智能家居设备在6月上市。
2016年6月13日，苹果开发者大会WWDC在旧金山召开，会议宣布建筑商开始支持HomeKit。而在不久前举行的2018
WWDC大会上，苹果在新发布的iOS 12和tvOS
12中，赋予了HomeKit一项重要功能——支持第三方遥控器。如今经过4年多的开发和建设，HomeKit平台在家庭自动化市场中终于要站稳脚跟了。
例子：一个高速路有10个入口，每个入口每秒钟只能进1辆车
1、请问1秒钟最多能进几辆车？
TPS=10
2、每辆车需要多长时间进行响应？
reponse time = 1
3、改成20辆车，每秒能进几辆？每辆车的响应时间是多长？
TPS = 10，reponse time = 1 (10个为一等份，分成两等份，平均tps
(10/1+10/2)/2=7.5 平均响应时间(2+1)/2=1.5
4、入口扩展到20个，每秒能进几辆？每辆车的响应时间是多长？
TPS = 20，reponse time = 1
5、看看，现在TPS变了，响应时间没变，TPS和响应时间有关系吗？
木有关系
6、如何理解？
TPS和响应时间在理想状态下都是额定值(联想运行一个压力测试场景来考虑)，把入口看成线程池，如果有20个入口，并发数只有10的时候，TPS就是10，而响应时间始终是1，说明并发数不够，需要增加并发数达到TPS的峰值。
7、同样是20个入口，如果并发数变成100的话，TPS和响应时间会怎么样呢？
并发数到100的时候，就会出现堵车，堵车了平均每个车过去的时间就长了，把100个车按照20一份分成5份，第5份的等待时间就是最长的，从等待开始到这个车进去，实际花费了5秒，那100辆车都过去的响应时间就是（5+4+3+2+1）/5=3，平均的TPS就是（20/1+20/2+20/3+20/4+20/5)/5=9.13（我怎么感觉应该是100/（5+4+3+2+1）=6.67
完成的事务总数/完成事务数的时间，使用该方法计算出来的tps会稍微小些,可以乘以1.5倍作为当前tps）
8、由此可知，TPS和响应时间宏观上是倒数关系，但是两者实际上木有直接的关系的，在上例中，系统只存在20个线程，100的并发就会造成线程的等待，引起平均响应时间从1秒增加到3秒，TPS从20下降到9，TPS和响应时间都是单独计算出来的，并不是互相算出来的！
9、同样可知，在并发量保持不变的情况下，提高TPS的手段有几种？
A、增加线程池的数量（入口）B、降低每辆车入关的时间（也就是提高单个线程的处理效率）
10、从TPS和response time的定义查看这2者的区别？
TPS =
在场景或者灰化步骤运行的每一秒钟中，每个事务通过、失败以及停止的次数
也就是说，TPS =
总的通过、失败的事务总数/整个场景的运行时间；
reponse time = 每个事务完成实际需要的时间/事务处理数目
因此，这2个东西压根就是木有关系的！