To Do List
-
mongoDB数据库学习
-
vertX框架学习
-
案例整理
mongoDB
这部分学习分为五块：非关系型数据库概念理解、数据库的增删改查操作、索引、聚合、查询解释。在数据库的增删改查学习中，因为对数据库操作熟悉所以比较容易上手。只是mongoDB数据库引入了 “文档” 这一新的概念，和关系型数据库 "表" 的概念类似。所以这里操作相较于关系型数据库不太一样，要记住它的操作格式以及操作指令。具体的学习记录在我博客《mongoDB入门一》一文中。地址：https://www.jianshu.com/p/cb067562fe3b
在对索引的学习中，知道数据库每次查询数据其实是要遍历文档的，这里就会有性能瓶颈。因此通过索引，来跳过遍历过程之间对指定field进行查询，并能以一定的顺序展现。另外，索引分为三种：
-
单字节索引：最简单的索引
-
多字节索引（复合索引）：可以同时有多个参照标准
-
多键索引：针对数组
这部分的学习记录在博文《mongoDB入门二》中，地址：https://www.jianshu.com/p/b4d0a50f9643
在聚合的学习中知道了聚合管道的概念，它其实就是mongoDB数据库为了将查询操作分步而引入的概念。例如，先对集合进行过滤，再把结果按特定要求呈现。这里有大量的操作指令，我也通过对官方文档的查阅重点记了一些重要的指令。这部分的学习记录在博文《mongoDB入门三》。地址：https://www.jianshu.com/p/f274c33ac9ee
查询解释（explain）这个东西，一开始我是不知道该如何称呼它的，直到看到一段对于它的解释恍然大悟：
通过查看一个查询（find）的explain()输出信息，可以知道查询使用了哪个索引，以及是如何使用的。 最常见的输出有两种类型：使用索引的查询和没有使用索引的查询
其实这个explain是用来优化我们的查询结构的。因为我们的查询结构本身或许就是不简洁、不优美的，导致查询性能不高。这是就可以通过这个explain来查看查询结构，并且我们就能优化查询了。
vert.X
vert.X框架的学习还没进行多久，从概念，流程层面掌握了一下基础。通过学习，知道了vertX其实是一个开源的java框架，用来编写全异步的服务器端程序的。它的特点就是灵活、高效。但同时它也是有缺点的（回调地狱、异常处理）。在这个框架中有几个重点
-
Event Bus：这个是vertX的核心。正因为有了这个所有的异步执行单元才能够相互通信
-
Verticle：它是类似整个框架的基本单位，称之为执行单元。
-
Context：即可执行单元的“上下文”。这里的上下文只做一件事情，就是处理Handler里的内容。
-
Shared Data：它是VertX提供的简单的Map和Set，用来解决各个Verticle之间的数据共享。
VertX回调地狱
问题：vertX的回调地狱完全是因为它全异步的特性造成的。但是也正因为全异步，这个框架才能更好的发挥性能优势，所以这个回调地狱是必然的。
解决方案：可以利用类似委托的设计方法，设计一个类型，接受回调，使得回调能够加上去。
VertX异常处理
问题：因为是异步操作，所以不可以再第一层回调外套一层异常捕获，因为内层回调可能会超出外层作用域。
解决方案：可以采用由调用方提供错误处理回调的方案来解决。
技术路线
客户端：OnGUI、动画、场景、导航、烘焙、特效、音效、打包（安卓/IOS）、优化
编程：C#、XLUA、shader、Java
服务器端：Vert.X、mongoDB
版本控制工具：git / sourceTree / SVN / GitLab
方案设计原则
-
需求分析（边界分析、异常分析）
-
方案设计（方案比较选择）
-
数据库设计（可配置的、固定的存在数据库中。可变的）
-
接口设计
-
客/服设计
-
合并
案例：背包的数据库设计
利用mongoDB来表现玩家背包中有1000个金币的情形。
{
player_id：001
bag:{
item:{
{item_id:01,item_count:1000}
}
}
}
案例：体力机制设计
描述：设计一种最高60点，每6分钟恢复1点的体力机制。
分析：
-
不变量：上限60、每分钟恢复6点
-
变量：当前体力值、查询时间
注意点：体力不需要通过计时器等方法不断访问修改，他只需要在要被外力修改的时候（例如下副本或者喝体力药水）访问即可。
接口设计：在类中封装修改体力的函数就收一个修改参数作为修改依据。当前体力的计算公式应该是： 当前体力 = 数据库中体力记录 + ((t-(t-t0)%6)-t0)*6
客户端在下副本或喝药水的时候向服务器发送当前体力请求并传入参数，服务器在接受请求时先返回计算出的当前体力，再把修改后的体力保存数据库。
案例：等级机制设计
描述：现在有两种等级机制设计，哪一种机制更好，阐述理由。
-
已有总经验对应的等级。比如1级时总经验一定要达到100exp
-
升级所需的经验。例如1级对应100exp,表示升级要100点才可以
第一种方法：当获取经验后加到人物目前经验上，计算等级的方式是通过遍历等级表然后确定等级
第二种方法：用获得经验遍历表，知道表数据累加结果大于获得经验，然后再确定等级。
很显然的一种更直接。
案例：提醒“红点”
描述：描述提醒红点的实现原理
答：通过分层，由底层消息节点在状态发生改变之后向上层通知，知道根节点。
网友评论