数据存储

在2015年，我们Lumins Technolgoies在亚马逊的EC2上面运行配置很多年之后，我所在的团队接到任务，负责为Lumins Technolgoies所有其他开发团队的配置创建一个新的配置平台。过去这么多年，AWS的设置运行得很好。但是配置设置，定制脚本，和自动配置的工具这些东西，对于操作团队以外的工程师来说十分难用——特别是对没有资源来学习所有关于这些脚本和工具的团队来讲。主要的问题就是没有配置单元，因为没有，所以在开发和操作之间有一个鸿沟。显然，容器化趋势将会改变这个状况。 如果你还没有了解Docker和Kubernetes能够带给产品什么，那么来读一读我们团队是如何成为早期使用者的。我们目前已经在生产过程中使用Kubernetes超过一年了。 从容器和容器编排工具开始 现在我相信容器是未来的配置编排格式。他们使得用需要的基础设施来打包应用程序变得更加容易。虽然像Docker这样的工具提供真实的容器，但是我们也需要工具来处理例如像replication，failover以及API来自动化部署到多个机器。 在2015年初的时候，像Kubernetes和Docker Swarm这样的集群工具还不成熟，只有一个早期的alpha版本。我们仍然尝试使用它们，最开始的时候使用的是Docker Swarm。 首先，我们使用Swarm来处理我们自己的网络连接

有时候运维人员会直接拷贝数据库文件给我们，这个时候就需要把数据还原到mysql中，注意mysql版本要对应（也可以版本高一点），mysql所在的操作系统也注意最好一样（有一次window的到linux的mysql，就有部分表无法恢复），首先参考mysql数据储存文件个格式，参考： mysql数据库引擎和他们文件存储介绍 。 针对myisam数据库引擎文件，每个表有.myd，.myi，.frm三个文件，这种数据库引擎的表很好恢复，直接把这三个文件复制到新的库中，有以下需要注意的地方。 要文件的所有者修改为mysql，因为如果用root账号传输文件，文件的所有者就变成了root。 还原到新库的mysql版本一定要跟原来的mysql版本一样，或者高一点也行。有一次还原到低一点的版本，总是报错，因为版本不同文件内部的存储格式可能会有变化。 针对innodb数据库引擎文件。这种数据库引擎分共享表空间和独立表空间。注意mysql版本也要对应或者新的mysql版本稍高一点也行。 共享表空间，这种表空间有/var/lib/mysq/ibdata1和在数据库中的.frm文件，还有logfile，应该就是把这三种文件复制到新库中，也要注意传输文件后修改文件的拥有者。 独立表空间，有ibdata1文件和每个表的.ibd、.frm文件，这种方式很简单，直接把文件复制到mysql的数据目录中

一、JS中的三种数据存储方式 cookie、sessionStorage、localStorage 二、cookie cookie的定义： cookie是存储在浏览器上的一小段数据，用来记录某些当页面关闭或者刷新后仍然需要记录的信息。在控制台用 document.cookie 可以查看当前正在浏览网站的cookie。 cookie存在的问题： cookie虽然很方便，但是使用cookie有一个很大的弊端，cookie中的所有数据在客户端就可以被修改，数据非常容易被伪造，那么一些重要的数据就不能放在cookie中了，而且如果cookie中数据字段太多会影响传输效率 三、sessionStorage 当用户用账号和密码登录某个网站后，刷新页面仍然保持登录的状态，服务器如何分辨这次发起请求的用户是刚才登录过的用户呢？这里就是用session保存状态。 用户在输入用户名密码提交给服务器，服务端验证通过后会创建一个session用于记录用户的相关信息，这个session可保存在服务器内存中也可保存在数据库中。 创建session后，会把关联的session_id通过setCookie添加到http相应头部 浏览器在加载页面时发现响应头部有set-cookie字段，就把这个cookie种到浏览器指定域名下 当下次刷新页面时，发送的请求会带上这条cookie

物理结构(普通的HDD) 主引导扇区位于0磁道，1扇区，共512bytes(主引导MBR446bytes 分区表64bytes：4个主分区，每个分区16bytes： 硬盘有效标识 2bytes) 低格：划分磁道，创建分区（一般出厂的HDD已经做好了，我们装上机器只需要高格）； 高格：即格式化，创建文件系统 硬盘的两个数据存储区： stat 文件名查看文件元数据，文件名称存放于文件条目中 1元数据区 2数据存储区 inode inode位图 块位图 块的概念：4个扇区组成一个块，即是4K（512bytes x8） 我们买到的U盘，硬盘大小和我们在电脑中看到的大小不一致，是由于元数据区兵没有显示出来，只显示了数据存储区的容量大小 来源： https://www.cnblogs.com/profileBlogs/p/11373990.html

Play 2.0 介绍 2007开始，我们一直致力于让Java开发web应用更容易。Play始于一个内部项目Zenexity，它深刻影响了我们开发web项目的方式：关注开发者生产力，遵循web架构的特点，并打破常规，使用新的打包方式－－因此称为JEE最佳实践是有道理的。 2009年，我们决定在社区中以开源项目的方式分享成果。该举动立即得到了极积的关注与反馈，项目也越来越受欢迎。如今－－经过两年的活跃开发 － Play已拥有多个版本，建立了一个4000多人的活跃社区，越来越多的应用被部署于生产环境。 开源分享意味着会收到更多的反馈，也意味着能发现和学习更多的新用例，新特性，和在原先的设计中忽视的潜bugs。两年期间，我们修复了某些问题，同时增加了某些新特性来支持更广泛的场景。伴随项目的成长，我们从社区和自身的经验中学到了很多很多 －－ 正在使用Play部署更复杂更大型的项目。 同时，技术和web也在持续发展。web已经变成所有应用的中心。HTML，CSS，JavaScript的技术也在快速变革 － 几乎使得服务端框架跟不上步伐。几乎所有web架构都在迅速的向实时应用靠拢，SQL数据库不再是数据存储的唯一选择。而在开发语言层面，我们也目睹了一些巨变，基于JVM的语言，包括Scala，正日益普及。 这就是Play 2.0项目诞生的原因，一个新时代的新web框架。 构建异步应用

英文原文： Things I wish I had known before starting iOS development—Part 2 如果你还没读这篇文章的第一部分，请先读完了再来看第二部分。 那些在学习iOS开发前就应该知道的事（part 1） ： 设计师设计出来了一个不错的引导界面，然而当我看到设计稿的时候，我们的app也没几天就要上线了…… 在第一部分中，我讨论了学习iOS开发的一些基本问题。第二部分将更多地讨论一些实际问题，这些问题都是你在开发iOS应用时会遇到的。 Debugging 毋庸置疑，你在开发应用的过程中一定会遇到很多错误和异常。比如，你会遇到NSInvalidArgumentException，遇到NSInternalInconsistencyException，还会遇到“0xfaded322”这种错误代码。有时候你可以在Stack Overflow或Quora上找到答案，但大部分时候你得自力更生。 Xcode具有断点、视图调试和日志的功能，是debug的不二之选。但毕竟孤掌难鸣，你仍需为它找些得力的帮手。 1.Pony Debugger square/PonyDebugger ： PonyDebugger - 使用Chrome Developer Tools，为你的native iOS应用进行远程网络和数据调试。 square开发了这个强大的开源工具

8月14日，阿里云宣布正式推出小程序Serverless，阿里云小程序Serverless提供包括云函数、数据存储、文件存储等一整套后端服务开发套件，以及集成了经济体业务能力API的业务套件。开发者通过API方式即可获取云函数、数据存储、文件存储等IaaS层技术能力，不需要关心服务器或底层运维设施，可以更专注于代码和业务本身。也可以在函数里直接使用阿里经济体内比如支付宝的会员、支付、卡券等业务能力。结合小程序开发者IDE工具，还可以体验从代码开发到代码发布的一站式研发流程。 • 云函数 云函数服务支持使用Node.js进行开发。作为开发者，您可以通过小程序IDE将代码提交到云端运行，在客户端使用Serverless提供的API进行调用。您还可以在云函数中直接通过API调用数据存储和文件存储的服务资源。 • 数据存储 数据存储服务是基于MongoDB托管在云端的数据库，数据以JSON格式存储。数据库中的每条记录都是一个JSON格式的对象。一个数据库可以有多个集合（相当于关系型数据中的表）。大家可以在客户端（如支付宝小程序）内直接操作数据，也可以在云函数中读写数据。 在小程序客户端代码里，我们可以通过 mpserverless.db对象调用数据存储的大量 API 方法，也可以通过云函数直接调用同一个服务空间的数据库服务。 • 文件存储 文件存储服务支持文本

文章转载自: http://www.pythonheidong.com/blog/article/4052/ 最近主要忙着功能开发，一时感觉没什么值得分享的。索性就数据存储这个话题聊聊，顺便自己也理一下思路，希望后面做起来能顺利一点，目前我们项目数据存储还完全没做，只是简单的把每个玩家数据单独存一个文件在硬盘上:-) 关于性能 网络游戏的数据存储有其特殊性。游戏是交互性比较强的产品，对系统响应时间的要求特别高，如果在处理逻辑时同步地去进行数据库IO是不可接受的。另外玩家在游戏过程中数据变化非常剧烈，也就是说写数据的频率会特别高，如果设计不合理，数据存储是很容易成为系统瓶颈的。 不妨拿BBS系统来做一个比较。我们逛BBS时大部分时间都是在浏览，相比之下发帖行为是小概率事件。用户花20分钟写完一个帖子点击发布按钮，3秒钟或10秒钟后提示发送成功都是完全可以接受的，甚至提示发送失败要求用户重新再发一次也不是什么大问题。所以对于上述BBS系统，在用户提交请求时同步去读写数据库是完全可行的。而网络游戏要做的是同时支持数千人以数秒为间隔不停地发贴，要保证响应时间控制在数毫秒内，还要保证发出去的帖其他人能立即看到。 业内的通行做法是将数据库的职能尽量简化，只拿数据库做数据最终的备份仓库来用。即在服务器进程启动时从数据库中加载所有的全局数据，在玩家上线时从数据库中加载玩家的所有数据

海量数据处理是基于海量数据上的存储、处理、操作。 所谓海量，就是数据量很大，可能是TB级别甚至是PB级别，导致无法一次性载入内存或者无法在较短时间内处理完成。面对海量数据，我们想到的最简单方法即是分治法，即分开处理，大而化小，小而治之。我们也可以想到集群分布式处理。 1 海量数据的存储：为大数据分析做准备 传统关系型数据库 传统关系型数据库在 数据存储上主要面向结构化数据，聚焦于便捷的数据查询分析能力、按照严格规则快速处理事务（transaction）的能力、多用户并发访问能力以及数据安全性的保证。其结构化的数据组织形式，严格的一致性模型，简单便捷的查询语言，强大的数据分析能力以及较高的程序与数据独立性等优点获得广泛应用。 但是 面向结构化数据存储的关系型数据库已经不能满足当今互联网数据快速访问、大规模数据分析挖掘的需求。 它主要缺点： 1) 对于半结构化、非结构化的海量数据存储效果不理想。像电子邮件、 超文本、标签（Tag）以及图片、音视频等各种非结构化的海量数据。 2）关系模型束缚对海量数据的快速访问能力： 关系模型是一种按内容访问的模型。即在传统的关系型数据库中，根据列的值来定位相应的行。这种访问模型，会在数据访问过程中引入耗时的输入输出，从而影响快速访问的能力。虽然，传统的数据库系统可以通过分区的技术（水平分区和垂直分区） ，来减少查询过程中数据输入输出的次数以缩减响应时间

gRPC快速入门（二）——Protobuf序列化原理解析 一、Protobuf序列化原理简介 1、序列化 序列化是将数据结构或对象转换成二进制字节流的过程。 Protobuf对于不同的字段类型采用不同的编码方式和数据存储方式对消息字段进行序列化，以确保得到高效紧凑的数据压缩。 Protobuf序列化过程如下： （1）判断每个字段是否有设置值，有值才进行编码。 （2）根据字段标识号与数据类型将字段值通过不同的编码方式进行编码。 （3）将编码后的数据块按照字段类型采用不同的数据存储方式封装成二进制数据流。 2、反序列化 反序列化是将在序列化过程中所生成的二进制字节流转换成数据结构或者对象的过程。 Protobuf反序列化过程如下： （1）调用消息类的parseFrom(input)解析从输入流读入的二进制字节数据流。 （2）将解析出来的数据按照指定的格式读取到Java、C++、Phyton对应的结构类型中。 二、Protobuf编码方式 1、Varint编码 Varint编码是一种变长的编码方式，编码原理是用字节表示数字，值越小的数字，使用越少的字节数表示。因此，可以通过减少表示数字的字节数进行数据压缩。 对int32类型的数字，一般需要4个字节表示。如果采用Varint编码，对于很小的int32类型数字，则可以用1个字节来表示；虽然大的数字会需要5个字节来表示，但大多数情况下