梦启未来

先看一个简单的例子，在计算机中是有大端序和小端序之分的，大端序就是大家正常的阅读习惯，比如 "今天你吃了吗",而小端序是计算机喜欢的阅读习惯比如刚才那句话，计算机用小端序就是 "吗了吃你天今"。小端序的好处就是计算机处理的更快，当然坏处就是人看起来难受，所以计算机底层的核心逻辑以外，大部分还是选择了大端序，毕竟这样排bug更方便一些。一，go的大端序和小端序。二，序列化与反序列化实现。

其实简单的来说，cobra就是一个自定义命令工具，我们经常使用一些命令来构建项目，但是这些命令都是go自带的，你想写自己的命令就可以使用cobra库来试一试。二，简单的cobra项目先构建一个简单的cobra命令，以此来熟悉cobra是怎么用的创建一个cmd目录，在目录里创建一个myOrder.go，实际上这个名字可以随便命名，一般来说，你创建的啥命令就写啥名字，这不是为了好找么。然后在main.go 入口里运行Execute即可main.go ↓cobraTest是这个项目的名字，c

这个效果其实有很多种写法，现在选取一个简单的写法，通常的写法是让两个协程交替打印，用chan来阻塞通知，但是由于大部分的demo都没有考虑优雅退出的问题，这次的demo添加了一个stopCha来优雅退出并close通道。

第二，A服务按理说只能去掉自己的服务加上的锁，如果不止是有AB两个服务，有更多的服务，那么A如果出现处理较慢，锁超时后，B服务抢到锁，A又处理完成所有的事释放了锁，那其实是释放掉了B的锁。也就是说，释放锁的时候也必须判断是否是自己的锁。第一，当A服务（本案例中其实是协程模拟的）拿到锁之后，处理超时了，锁还没有释放，就已经过期，过期后B服务就抢到了锁，此时AB均认为自己拿到了锁。但是这种锁只能用于你自己的本地服务，一旦出现多服务，比如分布式，微服务，这样的场景，这个锁就没啥用了，这就需要分布式锁。

redis的集合是 无序、不重复的集合，如果一个抽奖系统只需要简单的从一堆数据里抽出一部分，那么redis就可以简单的实现。主要用到了SPOP(随机移除并返回集合中一个或多个元素) 和 SRANDMEMBER(随机返回集合中一个或多个元素)

如果某一个协程发现打印的数字超过了设定的数字，这时候就会通知下一个协程close信号，然后下一个协程再通知下下个协程close，最后返回给主协程，类似计算机网络中的 环状网络。这里主要是形成一个闭环，每一个协程要打印的时机和数字是来自上一个协程的控制，最终有主协程（类似主持人角色）把最后一个协程的信号转发给第一个协程，从而形成闭环。如果我们每一个协程都生成一个管道，通知下一个协程什么时候能打印，打印哪个数字，这个问题就非常好解了。nextChannel(第一个协程生成)放入firstChannel。

今日学习grpc通信，做一个简单的小demo来验证效果。

begoo（1.12版本）没有现成的json处理方式，需要自己手动处理1，ctx获取requestBody里面的内容2，json.Unmarshal解析jsonpackage mainimport ( "encoding/json" "fmt" "github.com/astaxie/beego")type TaskController struct { beego.Controller}func (c *TaskController) Json() { // 读取re

func main(){ guessNum(58)}/**猜数字 */func guessNum(insertNum int) { temp := 0 n := 0 for { temp = randNum(int64(n)) n++ if (temp != insertNum) { println("Not equal,Now is ",temp) } else { println("Equal! Now is",temp) break } }.

我服了，网上找个资料哪来那么多废话，我只是要个能用随机数而已func main(){ fmt.Println(randNum())}/**任意数字*/func randNum() int{ // 取当前时间戳 var timeStamp = time.Now().Unix() // 构造一个rand，并使用时间戳作为他的随机种子 r := rand.New(rand.NewSource(timeStamp)) // 取100以内的随机数 num := r.I