信息存储

彻底理解cookie，session，token 发展史 1、很久很久以前，Web 基本上就是文档的浏览而已， 既然是浏览，作为服务器， 不需要记录谁在某一段时间里都浏览了什么文档，每次请求都是一个新的HTTP协议， 就是请求加响应， 尤其是我不用记住是谁刚刚发了HTTP请求， 每个请求对我来说都是全新的。这段时间很嗨皮 2、但是随着交互式Web应用的兴起，像在线购物网站，需要登录的网站等等，马上就面临一个问题，那就是要管理会话，必须记住哪些人登录系统， 哪些人往自己的购物车中放商品， 也就是说我必须把每个人区分开，这就是一个不小的挑战，因为HTTP请求是无状态的，所以想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字串，每个人收到的都不一样， 每次大家向我发起HTTP请求的时候，把这个字符串给一并捎过来， 这样我就能区分开谁是谁了 3、这样大家很嗨皮了，可是服务器就不嗨皮了，每个人只需要保存自己的session id，而服务器要保存所有人的session id ！ 如果访问服务器多了， 就得由成千上万，甚至几十万个。 这对服务器说是一个巨大的开销 ， 严重的限制了服务器扩展能力， 比如说我用两个机器组成了一个集群， 小F通过机器A登录了系统， 那session id会保存在机器A上， 假设小F的下一次请求被转发到机器B怎么办？ 机器B可没有小F的

1、酒店预订怎么实现？怎么设计表 你好，我大概的说下我们的业务流程，我们的业务流程是：用户在网站浏览酒店信息，可以根据地区检索出该地区的酒店信息。列表展示酒店的信息由：酒店的名称，酒店图片，酒店位置，评论人数，评论分数以及最低入住价格。用户选中要入住的酒店进入酒店详情页面，查看酒店的介绍以及酒店的房型列表，用户根据他要入住的时间和离店的时间，检索出这个时间段内的所有可选房型（房间数量-当天的订单-当天未离店订单=剩余房间数量）显示给用户。用户选择好房型后就可以进行下单，要求有订单的开始时间，结束时间，房间数量，住客姓名，抵店时间，联系方式，备注信息等等。 那我的表是这么设计的，总共有6张表，分别是： 用户表user，里面有下面几个字段，(用户编号，用户名称，用户密码，用户联系方式) 酒店表hotel，里面有(酒店编号，酒店名称，酒店图片，评论人数，评论分数，最低入住价格，所在地区) 酒店图片表pic(图片编号，图片地址，图片排序，图片所属酒店) 评论表comment(评论编号，评论内容，评论时间，用户编号，酒店编号) 房型表house(房型编号，床型，早餐，宽带，人数上限，房价，房间数量，最长预定时间) 订单表order(订单编号，开始时间，结束时间，房间数量，住客姓名，最晚抵店时间，联系电话，使用优惠券，备注，订单状态) 以上就是我对这个酒店预订系统的设计 2

老男孩教育基础阶段总结 服务器内部组成部分 主板 : 将多个硬件进行整合 传导电信息 硬盘 : 存储数据信息 永久存储 光驱 : 安装系统 安装软件 看电影 阵列卡 : (raid) ??? 将多块硬盘整合为一块 风扇 : 负责散热 CPU: 中央处理器 ( 大脑 ) 运算 ( 二进制 ) 控制其他硬件 内存 : 存储数据信息 临时存储 网卡 : 负责上网 电源 : 负责供电 硬件组成详细说明 · CPU( 大脑 ): 计算机工作原理 : 输入设备 --> CPU --> 内存 --> 硬盘 输出设备 <-- CPU <-- 内存 <--- 硬盘 路数 : 服务器 CPU 颗数 单路 1 颗 双路 2 颗 四路 4 颗 核数 : 同时处理多个任务能力越强 PS: 厂商服务器 IBM( 联想 ) DELL HP 浪潮 华为 · 硬盘 :(RAID) 接口 : 绝对了数据读和存效率 sata -- scsi -- sas 转速 : 家用硬盘 (5400 7200) 企业硬盘 (10k 15k) 多个硬盘进行组合 : RAID 01. 提高单块硬盘存储容量 02. 提高数据存储的效率 03. 提高数据安全性 · 内存 : 临时存储 程序 : 开发人员编写出代码 进程 : 运行起来的程序 进程编号 用户管理进程 会占用内存 临时进程 : 突然出现 , 很快自动消失 守护进程 :

从原理到应用，Elasticsearch详解 https://segmentfault.com/a/1190000020022504 elasticsearch 2.1k 次阅读 · 读完需要 49 分钟 54 简介 Elasticsearch（简称ES）是一个分布式、可扩展、实时的搜索与数据分析引擎。ES不仅仅只是全文搜索，还支持结构化搜索、数据分析、复杂的语言处理、地理位置和对象间关联关系等。 ES的底层依赖Lucene，Lucene可以说是当下最先进、高性能、全功能的搜索引擎库。但是Lucene仅仅只是一个库。为了充分发挥其功能，你需要使用Java并将Lucene直接集成到应用程序中。更糟糕的是，您可能需要获得信息检索学位才能了解其工作原理，因为Lucene非常复杂——《ElasticSearch官方权威指南》。 鉴于Lucene如此强大却难以上手的特点，诞生了ES。ES也是使用Java编写的，它的内部使用Lucene做索引与搜索，它的目的是隐藏Lucene的复杂性，取而代之的提供一套简单一致的RESTful API。 总体来说，ES具有如下特点： 一个分布式的实时文档存储引擎，每个字段都可以被索引与搜索 一个分布式实时分析搜索引擎，支持各种查询和聚合操作 能胜任上百个服务节点的扩展，并可以支持PB级别的结构化或者非结构化数据 架构 节点类型 ES的架构很简单

一、Cookie 是什么？ 　HTTP协议是无状态的，每一次数据交换完毕就结束，服务器端和客户端的链接就会关闭，每次交换数据都需要建立新的链接。例如：我逛淘宝买东西，我看上了易宝棒棒糖，而我下单的时候，服务器不知道我是谁，而我有个ID，你能通过 ID 识别我，现在你居然不知道我谁？我去，那我怎么付款？？？ 　　而我们的业务是有状态的，因此，产生了 Cookie，用于记录状态 。　 　　 Cookie 是服务器发送到用户浏览器并保存在本地某个目录下的文本内的 一小块数据 ，它会在浏览器之后向同一个服务器再次发起请求时被携带上。用于告知服务端两个请求是否来自同一浏览器。 　　 Cookie 是个存储在浏览器目录的文本文件，当浏览器运行时，存储在 RAM 中。一旦你从该网站或网络服务器退出，Cookie 也可存储在计算机的硬驱上。 二、 Cookie的用途 　1. 会话状态管理（如用户登录状态、购物车、或其他需要记录的信息）。 　　记录用户的登录状态是cookie最常用的用途。通常web服务器会在用户登录成功后下发一个签名来标记session的有效性，这样免去了用户多次认证和登录网站。 　　记录用户的访问状态，例如导航啊，用户的注册流程啊。 　2. 个性化设置（如用户自定义设置、主题） 　　Cookie 也经常用来记忆用户相关的信息，以方便用户在使用和自己相关的站点服务。 　　　　例如

[last updated:2014/11/27] NO1. 常量池在class文件的什么位置？ 我的上一篇文章 《Java虚拟机原理图解》 1、class文件基本组织结构 中已经提到了class的文件结构，在class文件中的魔数、副版本号、主版本之后，紧接着就是常量池的数据区域了，如下图用红线包括的位置： 知道了常量池的位置后，然后让我们来揭秘常量池里究竟有什么东西吧～ NO2. 常量池的里面是怎么组织的？ 常量池的组织很简单，前端的两个字节占有的位置叫做 常量池计数器 ( constant_pool_count )，它记录着常量池的组成元素 常量池项( cp_info ) 的个数。紧接着会排列着 constant_pool_count-1 个 常量池项( cp_info ) 。如下图所示： NO3. 常量池项 (cp_info) 的结构是什么？ 每个 常量池项( cp_info ) 都会对应记录着class文件中的某中类型的字面量。让我们先来了解一下 常量池项( cp_info ) 的结构吧： JVM虚拟机规定了不同的tag值和不同类型的字面量对应关系如下： 所以根据cp_info中的tag 不同的值，可以将cp_info 更细化为以下结构体： CONSTANT_Utf8_info,CONSTANT_Integer_info,CONSTANT_Float_info

1、Zookeeper 的由来 在Hadoop生态系统中，许多项目的Logo都采用了动物，比如 Hadoop 和 Hive 采用了大象的形象，HBase 采用了海豚的形象，而从字面上来看 ZooKeeper 表示动物园管理员，所以大家可以理解为 ZooKeeper就是对这些动物（项目组件）进行一些管理工作的。 对于单机环境多线程的竞态资源协调方法，我们一般通过线程锁来协调对共享数据的访问以保证状态的一致性。 但是分布式环境如何进行协调呢？于是，Google创造了Chubby，而ZooKeeper则是对于Chubby的一个开源实现。 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。它被设计为易于编程，使用文件系统目录树作为数据模型。 2、ZooKeeper集群模式典型架构 2.1 角色 Zookeeper服务自身组成一个集群(2n+1个服务允许n>=1个失效)。Zookeeper集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种 Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader

顺序表 在程序中，经常需要将一组（通常是同为某个类型的）数据元素作为整体管理和使用，需要创建这种元素组，用变量记录它们，传进传出函数等。一组数据中包含的元素个数可能发生变化（可以增加或删除元素）。 对于这种需求，最简单的解决方案便是将这样一组元素看成一个序列，用元素在序列里的位置和顺序，表示实际应用中的某种有意义的信息，或者表示数据之间的某种关系。 这样的一组序列元素的组织形式，我们可以将其抽象为 线性表 。一个线性表是某类元素的一个集合，还记录着元素之间的一种顺序关系。线性表是最基本的数据结构之一，在实际程序中应用非常广泛，它还经常被用作更复杂的数据结构的实现基础。 根据线性表的实际存储方式，分为两种实现模型： 顺序表 ，将元素顺序地存放在一块连续的存储区里，元素间的顺序关系由它们的存储顺序自然表示。 链表 ，将元素存放在通过链接构造起来的一系列存储块中。 一、顺序表的基本形式 图a表示的是顺序表的基本形式，数据元素本身连续存储，每个元素所占的存储单元大小固定相同，元素的下标是其逻辑地址，而元素存储的物理地址（实际内存地址）可以通过存储区的起始地址Loc (e0)加上逻辑地址（第i个元素）与存储单元大小（c）的乘积计算而得，即： Loc(ei) = Loc(e0) + c*i 故，访问指定元素时无需从头遍历，通过计算便可获得对应地址，其时间复杂度为O(1)。 如果元素的大小不统一

第十五章 网络 15.1 联网 1.计算机之间的连接通常是靠物理电线或电缆实现的。但是，有些连接使用无线电波或红外信号传导数据，这种链接是无线的。 2.==计算机网络中的设备不只是计算机==。例如，打印机可以直接连入网络，一边网络中的每个用户都可以使用它。 3.多媒体成分（如音频或视频）是使通信量大增的主要贡献者。 计算机网路(computer network) ：为了通信和共享资源而连接在一起的一组计算设备。 无线连接(wireless) ：没有物理电线的网络连接。 节点（主机）(node(host)) ：网路中任何可寻址的设备。 数据传输率（带宽）(data transfer rate (bandwidth)) ：数据从网路中的一个地点传输到另一个地点的速率。 4.在联网过程中，我们使用明确的协议来说明如何格式化和处理要传输的数据。 5.协议(protocol)：定义如何在网路上格式化和处理数据的一组规则。 6.客户/服务器模型(client/server model)：客户发出对服务器的请求，服务器做出响应的分布式方法。 7.文件服务器(file server)：专用于为网路用户存储和管理文件的计算机。 8.Web服务器(Web server)：专用于响应网页请求的计算机。 15.1.1 网络的类型 1. 局域网(Local-Area Network,LAN)

一、文件系统概述 软件资源管理 信息长期保存的需要 存储介质：磁盘、光盘、磁带… 完成外存信息的管理和存取 在前面的学习中，我们知道文件也是一种系统资源。 这里先给出文件和文件系统的定义。 1、文件 外存中具有符号名的一组有逻辑意义的信息项的集合。 2、文件系统 指OS中管理文件的那一部分软件。它负责管理文件的存储、检索、更新，提供安全可靠的共享和保护手段，并为用户提供一整套方便有效的文件使用和操作方法。它在OS接口中占比例最大，是I/O系统的上层软件。文件系统面向用户的主要任务是实现文件的 “按名存取” 。 按名存取是文件系统最为主要的任务！！！ 3、文件的属性 主要属性有：文件名、识别符、类型、位置、大小、创建时间、上次修改时间、文件所有者和保护信息等。 UNIX系统中文件属性： － 普通文件 d 目录文件 p 管道文件 c 字符型设备文件 b 块设备文件 4、文件的分类 按性质和用途分： 系统文件、库文件、用户文件 按数据形式： 源文件、目标文件、可执行文件 按对文件实施的保护级别分： 只读文件、读写文件、执行文件 按逻辑结构分： 有结构文件、无结构文件 按文件中物理结构分： 顺序文件、链接文件、索引文件 二、文件的逻辑结构 文件的结构指文件中信息的配置和构造方式，有逻辑结构和物理结构之分。 用户眼中文件信息的组织形式叫文件的逻辑结构 。它包括记录式文件和流式文件两种