minecraft UUID的存放位置在哪

uuid这个东西国内用的貌似很少吧。

大概的位置也就是世界存档里面，服务器的登录插件里也有。

客户端找法：打开我的世界所在目录——minecraft——saves——找个你玩过的地图文件夹打开——playerdata——然后那个数字和字母组合中间有几个杠的就是了。

服务器找法（两种）：

打开服务器目录——world——playerdata——同上

（前提是用的authme登录插件，其他插件的我就不知道了）打开服务器目录——plugins——AuthMe——authsdb（用notepad++打开，只要会调插件配置的一般都能看懂我就不细说了）

只可能是服务器出问题了，换个时间点再试试就好了
uuid一般是网站内部使用的，在页面上不会直接显示这部分内容，如果出现了，那么肯定是服务器出问题了，只能重新登入网站或者换个时间点访问
按照实名认证的基本逻辑流程
首先你要是个已登陆的用户，就是说你在其他页面上已经通过显式（通过用户名和密码）或者隐式（通过”记住我“功能）登陆进入天猫的网站，在这一步，服务器会分配给你一个唯一的字符串也就是uuid，当然不会显示出来。
然后，你要通过网站内某个链接进入到实名认证页面，这里，服务器首先检查你当前登录的用户与分配给你的uuid是否符合，如果符合则允许你进一步处理，否则会报如上错误。这样的检查会在你进行任意一项关键 *** 作时进行，如提交你的认证材料，更改你的认证信息等
正常情况下，你在进行你的 *** 作时不会出错，除非你是个hack，伪造了认证数据，否则浏览器这边（也就是你这一边）一般不会出任何问题

在MySQL服务器1中，添加如下配置：

在MySQL服务器2中，添加如下设置：

在这里两台MySQL的配置文件，需要对auto_increment_offset字段，设定不同值。因为如果mysql中有自增长字段，不设定这个参数会起冲突，会报duplicate的报错。
auto_increment_offset表示自增长字段从那个数开始，他的取值范围是1 65535
auto_increment_increment表示自增长字段每次递增的量，其默认值是1，取值范围是1 65535
做主主同步配置时，需要将两台服务器的auto_increment_increment增长量都配置为2，而要把auto_increment_offset分别配置为1和2，这样可以避免两台服务器同时做更新时,自增长字段的值之间发生冲突。

配置好两台mysql的mycnf配置文件后，service mysqld restart 重启mysql服务。

在Mysql服务器1中，

在MySQL服务器2中，做如上同样的 *** 作，然后将服务器1的file和position值设定到服务器2中，服务器2的file和position值输入到服务器1中。

在MySQL服务器1中，输如下命令：

在MySQL服务器2中，输如下命令：

范例如下图：

配置完后，分别在两台服务器上输show slave status ;
如果出现如下两个字段都是on的状态，则主主备份搭建完成。

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

在实际测试配置中，由于MySQL服务器2是克隆的MySQL服务器1的，所以start slave 后，show slave status 出现了Slave_IO_Running: No ,然后有如下报错信息。告知是因为两个MySQL服务器的UUID相重复了。

只需要，将basedir,即/use/local/mysql/data中的autocnf文件删掉后，重启mysql，就会出现新的autocnf文件，里面有新的UUID

随着wx的普及对开发同学来说一些业务场景会使用到“扫码登录”功能，特别是PC网页端，在此之前没有这方面的开发经历，所以接到这个需求的时候还是有点慌的，最终通过查阅网上的资料以及老大的指导下实现了这个功能，目前已经投入使用，实现之后还是蛮兴奋的。特此记录一下实现的过程。

扫码登陆的实现需要手机端的服务器和Web端的服务器配合实现。大致分为以下几步：

step1：网页端请求登陆二维码

要实现网页版的扫码登陆，用户必须先要请求一个登陆的二维码。Web端的服务器收到用户申请登陆二维码的请求后，会随机生成一个uuid（这个uuid作为页面的唯一标识符），并且会将这个uuid当做一个键值对的key存入后台Redis。存入Redis的这个键值对的value是什么我们待会再说。

需要注意的是存入Redis的键值对必须设置一个过期时间，不然的话拿着这个uuid登陆一次后就一直处于登陆状态了。

当浏览器端拿到Web服务端返回的二维码信息后，解析其中的uuid，并拿这个uuid不断去后台轮询是否已经登陆成功。如果后台已经登陆成功，Web端就自动跳转到登陆成功页面。不然的话会一直轮询，直到二维码失效（这里我们发现给二维码设置有效时间真的很有必要，如果二维码没有有效时间的话，会不断的轮询后台，给后台造成很大的压力）。

那么上面的关键点是Web端服务器是怎么判断用户是否已经扫码登陆成功过的呢？ 请看下面的步骤。

step2：手机端将用户id存入Redis

用户请求到二维码后，就开始拿出手机，打开相应的App扫描二维码。扫描过程中手机会将uuid和手机端登陆后获得的token信息一起提交到手机端服务器。

手机端服务器会先拿token信息判断这个用户是否合法，是否已经正常登陆。如果判断已经正常登陆，那么会将这个用户的userId和提交过来的uuid当做一个键值对（uudi-userId）存入Redis。这边回答了步骤一种留下的问题。

简单来讲手机端做的工作就这么多。让我们继续回到Web端。

step3：web端轮询成功

步骤一中讲到：二维码登陆页会不停的轮询是否登陆成功。这边的依据就是Redis中存在uuid-userId键值对。如果这个键值对已经存在，说明手机端已经扫码登陆过。

Web端服务器一旦判断到手机端已经扫码登陆过，就可以拿着userId进行登陆。并将必要的用户信息和token信息返回Web前端。至此Web端登陆成功。

本文记录了一个扫码登陆的简单版本，但是也能描述扫码登陆的大致原理。实际开发过程中应该还是有许多细节需要考虑。比如安全问题等。具体的还是需要我们进行实战了。

欢迎大家一起讨论~

---