- 博客(270)
- 收藏
- 关注
RSS订阅原创 《Linux内核技术实战课》总结四：CPU
总览现代处理器：cpu伪共享：两个 CPU 上并行运行着两个不同线程，它们同时从内存中读取两个不同的数据，这两个数据的地址在物理内存上是连续的，它们位于同一个 Cache Line 中；CPU 从 内存中读数据到 Cache 是以 Cache Line 为单位的，所以该 Cache Line 里的数据被同时 读入到了这两个 CPU 的各自 Cache 中；紧接着这两个线程分别改写不同的数据，每次改写 Cache 中的数据都会将整个 Cache Line 置为无效；因此，虽然这两个线程改写的数据
2020-12-12 11:46:44
2122
原创 《Linux内核技术实战课》总结三：网络
TCP配置项连接过程：断开过程：TCP收发包配置项发送：TCP 发送缓冲区太小，导致业务延迟很大的问题可以使用 systemtap 之类的工具在内核里面打点来进行观察，如果观察到 sk_stream_wait_memory 这个事件，就意味着 TCP 发送缓冲区太小 了，需要调大 wmem_max 和 tcp_wmem:max 的值tcp_mem 是总连接数的内存限制，如果达到限制而无法发包或者产生抖动，可以观测静态观测点：sock_exceed_buf_limit，如果有日志输出（即发生
2020-12-12 11:45:01
1876
原创 《Linux内核技术实战课》总结二：内存泄漏
总览内存泄漏：内存被分配出去后 一直没有被释放，导致这部分内存无法被再次使用，更严重的是，指向这块内存空间的指针都不存在了，进而再也无法访问这块内存空间场景：服务器中的后台任务持续运行，系统中可用内存越来越少； 应用程序正在运行时忽然被 OOM kill 掉了； 进程看起来没有消耗多少内存，但是系统内存就是不够用了在遇到系统内存不足时，首先要做的是查看 /proc/meminfo 中哪些内存类型消耗较多，然后再去做针对性分析泄漏的内存可能是应用程序的内存泄漏、内核（操作系统）的内存泄漏；应用程序的
2020-12-12 11:42:57
1397
1
原创 《Linux内核技术实战课》总结一：PageCache
总览Page Cache：内核管理的内存场景：服务器的 load 飙高； 服务器的 I/O 吞吐飙高； 业务响应时延出现大的毛刺； 业务平均访问时延明显增加应用程序产生Page Cache的逻辑示意图，是在应用程序读写文件的过程中产生的产生，即被分配：有两种方式1 标准 I/O 是写的 (write) 用户缓冲区 (Userpace Page 对应的内存)，然后再将用户缓冲区里的数据拷贝到内核缓冲区 (Pagecache Page 对应的内存)；如果是读的 (read) 话则 是先从内核缓冲区拷
2020-12-12 11:39:21
2197
原创 《后端存储实战课》笔记
存储系统特点：难用、慢、场景多导致杂很多情况下，可供选择的存储方案不止一套，选择的时候需要考虑实现复杂度、性能、系统可用性、数据可靠性、 可扩展性等等非常多的条件，这些条件每一个都不是绝对不可以牺牲的以下内容以电商内容展开订单插入订单的幂等性问题：给订单系统增加一个“生成订单号”的服务，这个服务返回一个新的、全局唯一的订单号；在用户进入创建订单的页面时，前端页面先调用这个生成订单号服务得到一个订单号，在用户提交订单的时候，在创建订单的请求中带着这个订单号；重复时会报错，当然这种情况直接返回给前端
2020-11-28 14:59:47
1419
2
原创 《分布式数据库30讲》总结四：容灾
异地容灾：有灾难时，异地的应用系统会切换到备库异地读写分离：只读服务的数据一致性不保证双向同步：限制两地读写的对象为不同的数据，这样就保证不会冲突，但是两地仍然不能处理同样的数据以上三种是单体数据库的方式，分布式数据库的数据组织单位是更细粒度的分片，又有了 Raft 协议，所以就有了更加灵活的模式，如下机房级容灾：两地三中心五副本城市级容灾：三地五副本而上述方案只能达到容灾，即高可用，还没达到低延迟全球化部署的前提是多时间源、多点授时，这样不同分片的主副本就可以分散在多个机房，那么数据
2020-11-27 15:11:14
712
原创 《分布式数据库30讲》总结三：数据库查询
分布式数据库不推荐使用存储过程，因为移植性差、难以调试不推荐使用自增主键，因为只有唯一性，有时候达不到单调递增和连续递增；分布式数据库则在产生自增主键和使用自增主键两方面都有问题，生成自增主键时，要做到绝对的单调递增，其复杂度等同于 TSO 全局时钟，而且存在性能上限。使用自增主键导致写入数据集中在单个节点，出现“尾部热点”问题分布式数据库的主流设计理念是计算与存储分离，使计算比较容易实现无状态化，容易扩展，因此想要融合OLTP和OLAP，重点在存储上行式存储：列式存储：混合存储：融合了行和
2020-11-27 15:09:51
578
原创 《分布式数据库30讲》总结二：事务
原子性TCC、2PC、Percolator（2PC改进，改进第二阶段，不用commit两次）、GoldenDB（2PC改进，改进第一阶段，不用通信两次，直接跟事务管理器通信一次）以小明转账给小红2000为例：1 TCC：2PC：Percolator：GoldenDB：写操作优化方法：1 缓存写提交：将所有写操作缓存起来，直到 commit 语句时一起执行能减少一轮共识算法开销，但是1.1 如果某个业务场景同时存在长事务和海量并发的特点，那么这个缓存就可能被撑爆或者成为瓶颈1
2020-11-27 15:07:47
330
原创 《分布式数据库30讲》总结一：基础
分布式数据库含义：用分布式架构实现的关系型数据库，是服务于写多读少（写入能力需要可水平扩展）、低延时、海量并发 OLTP （联机交易）场景的，具有海量数据存储能力和高可靠性的关系型数据库需要达成的目标：存储、事务、查询、复制、其他分布式数据库的强一致性包括数据一致性和事务一致性，是两者的融合；数据一致性关注的是单对象、单操作在多副本上的一致性；事务一致性则是关注多对象、多操作在单副本上的一致性数据一致性：首先是状态视角，数据只有两种状态：所有副本一致或者不一致，不一致的状态是暂时，还会转换到一致
2020-11-27 15:03:13
921
原创 读《编译原理实战课》有感
1 词法分析、语法分析、语义分析是编译前端技术，核心就是为了让后端技术能理解代码，进行做操作2 词法分析核心就是构造自动机，通过状态流转来解析出一个个的“单词”，为token3 语法分析主要是搞成一个ast树，使用递归下降，识别出程序的语法结构，诸如优先级、结合顺序等，都是通过ast树的层次来实现的，越下越优先4 作用域、生存期等核心就是封装成栈帧5 语义分析，比如类型系统，核心就是做类型检查、类型推导和类型转换，通过写类似于业务逻辑的逻辑来实现就好6 IR充分体现了中间层的作用，适配器来着to
2020-11-25 20:58:55
728
1
原创 读《深入浅出计算机组成原理》有感
1 冯诺依曼体系本身就是一个值得学习的架构，为什么需要计算机？如何解决计算问题?如何解决存储问题？如何解决交互问题？等等引出了cpu、内存、外存、输入输出系统2 cpu有很多思想值得借鉴，为了性能等东西，搞出了流水线、冒险、预测、SIMD等等骚操作，还有高速缓存，又牵扯出了数据一致性的问题3 DMA本质就是用来减少冗余操作的，也是一个值得借鉴的思想：通过中间层来减少冗余4 异常和中断，在做架构设计时可以当成任何系统的出错处理手段todo...
2020-11-25 20:53:06
307
原创 读《许式伟的架构课》有感
1 架构应该是全貌的，从计算机组合原理、操作系统到存储、后端设计、前端设计等等，包括事后处理，如服务的治理，监控等2 开闭原则其实可以理解为“只读”todo
2020-11-25 20:48:07
626
2
原创 读《DDD实战课》笔记
DDD包含战略设计和战术设计，成型图：分层架构为四层，与传统三层的区别：还有整洁架构、六边形架构战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。对不同公司，相同业务不同核心域是不一样的，因为商业模式不同拆分需要限界上下文，也就是确保每个领域的通用语言语义唯一性聚合：
2020-11-25 11:24:07
1195
2
原创 关于重构的学习
参考《重构_改善既有代码的设计》1 有注释的代码，往往可以提取出一个函数出来；查询函数和修改函数也单独提取出来，同时使用时，使用一个新方法，加上sync锁就行2 变化频繁的地方可以使用多态来进行重构，争取每次的变化只需要新增一个对应类和修改配置3 ifelse过多/嵌套过深，可以考虑使用策略模式4 方法应该决定好归属的类，而不是都堆到一起，否则类会太大，实例变量也是一个道理，尽量将属于同一类的抽取出来成为单独的类，善用继承5 ifelse、while、for往往可以提取成一个单独的函数6 参数列
2020-10-07 20:54:07
171
原创 《Linux性能优化》总结：cpu性能、内存性能、文件系统性能、网络性能
来源极客时间总览uptime可查看系统平均负载：平均活跃进程数(可运行、不可中断)cpu个数：grep ‘model_name’ /proc/cpuinfo | wc -lmpstat：实时查看cpu性能指标（整体）pidstat：实时查看进程的cpu、内存、io、上下文切换等性能指标stress：压测iostat：io状态超过百分之70的使用率就该警醒cpucpu上下文切换：进程/线程/中断上下文切换vmstat：查看系统上下文切换情况、系统内存使用情况pidstat -w
2020-08-26 10:54:13
402
原创 《kafka核心源码解读》总结一：总览
kafak核心目录：bin 目录：保存 Kafka 工具行脚本，kafka-server-start 和 kafka-consoleproducer 等clients 目录：保存 Kafka 客户端代码，比如生产者和消费者的代码config 目录：保存 Kafka 的配置文件，如 server.propertiesconnect 目录：保存 Connect 组件的源代码,，该组件是用来实现 Kafka 与外部系统之间的实时数据传输的core 目录：保存 Broker 端代码，服务
2020-08-22 16:21:04
771
原创 《软件工程之美》总结四：系统设计、开发编码、软件测试、运行维护
架构设计复杂的软件项目通常有两个特点：需求不确定和技术复杂技术复杂主要体现在：需求复杂导致、人员过多导致、技术本身导致、软件稳定运行导致架构设计可以降低满足需求和需求变化的开发成本、可以帮助组织人员一起高效协作、可以帮助组织好各种技术、可以保障服务稳定运行什么是架构设计用最小的人力成本来满足需求的开发和响应需求的变化，用最小的运行成本来保障软件的运行架构设计的本质要求就是组织人员和技术把系统和团队拆分，并安排好切分后的排列关系，让拆分后的部分能通过约定好的协议相互通信，共同实现最终的结果步骤
2020-07-25 14:38:41
1525
1
原创 《软件工程之美》总结三：关于需求
需求分析什么是需求用户需求：是由用户提出来的，期望满足自身一定需要的要求产品需求：在分析提炼用户真实需求后，提出的符合产品定位的解决方案如何进行分析通过三个步骤，将用户需求提炼分析为产品需求1 挖掘真实需求分析出用户真正想要的东西，比如用户说想要一辆很快的马车，其实就是要汽车要分析用户的真实需求，可以从三个角度入手：1 目标用户：用户不同，诉求也不一样；2 使用场景：使用场景不一样，解决方案也会有所不同；3 想要解决的问题：用户背后想要解决的问题是什么2 提出解决方案3 筛选和验证
2020-07-24 21:46:13
218
原创 《软件工程之美》总结二：项目规划
可行性研究可行性研究通常讲的是如何科学地论证项目的可行性，以及这个项目是不是值得做对于软件项目的可行性研究，主要从三个方面入手： 经济可行性、技术可行性、社会可行性。经济可行性：从成本和收益角度分析，看投入产出比；不仅要分析短期利益，还要分析长期利益，看是不是值得做技术可行性：软件项目最终是需要人通过技术来实现的，所以要分析技术上是不是可行社会可行性：社会可行性涉及法律、道德、社会影响等社会因素项目管理需要逐步转变思维，从技术思维到工程思维，不要仅仅局限于自己负责的一个小模块，而是
2020-07-24 17:46:25
409
原创 《软件工程之美》总结一：基础理论
总览软件工程核心图：时间（多久可以完成）、范围（需要实现多少功能）、成本（花多少钱）决定了质量（产品的质量、客户的满意度）软件工程核心知识：围绕软件开发过程，产生的方法学和工具质量焦点：软件工程目标是聚焦于质量，构建和维护高质量的软件过程：在软件项目的生命周期内开发与构建系统时要遵循的步骤（瀑布模型、敏捷开发）方法：在整个过程中，如何构建系统的方法学（如何分析用户需求、如何对产品进行测试验收、如何进行系统架构设计等）工具：知道了过程，掌握了方法，具体落到操作层面，就会涉及到工具的使用软件工
2020-07-24 12:10:42
472
原创 《深入剖析Kubernetes》总结十一：容器启动
Kubeletkubelet负责将调度成功的 Pod在宿主机上创建出来，并把它所定义的各个容器启动起来kubelet 本身也是按照“控制器”模式来工作的，其工作原理如下：kubelet 的工作核心是一个控制循环，即：SyncLoop，还负责维护着很多很多其他的子控制循环（图中的小圆圈），这些控制循环一般被称作某某 Manager，比如 Volume Manager、Image Manager、Node Status Manager 等等；驱动SyncLoop控制循环运行的事件包括四种：Pod
2020-07-09 18:28:32
470
原创 《深入剖析Kubernetes》总结十：资源管理和调度
资源模型与资源管理资源模型设计CPU 和内存资源的限额要配置在每个 Container 的定义上，Pod 整体的资源配置，就由这些 Container 的配置值累加得到Kubernetes 里为 CPU 设置的单位是“CPU 的个数”，，具体“1 个 CPU”在宿主机上如何解释，是 1 个 CPU 核心，还是 1 个 vCPU，还是 1 个 CPU 的超线程（Hyperthread），完全取决于宿主机的 CPU 实现方式对于内存资源来说，它的单位就是 bytesKubernetes 里 Pod 的
2020-07-09 18:26:39
519
原创 《深入剖析Kubernetes》总结九：容器网络
容器网络总览Linux 容器“网络栈”实际上是被隔离 在它自己的 Network Namespace 当中的，其包括了：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和 iptables 规则；对于一个进程来说，这些要素构成了它发起和响应网络请求的基本环境容器可以声明直接使用宿主机的网络栈，但是会引入共享网络资源的问题，比如端口冲突，所以一般希望容器进程能使用自己 Network Namespace 里的网络栈，即拥有属于自
2020-07-09 18:25:06
484
原创 《深入剖析Kubernetes》总结八：容器持久化存储
容器化一个应用中，对其“状态”的管理是比较麻烦的，而最常见的“状态”，则为存储状态。 所以剖析下 Kubernetes 项目处理容器持久化存 储的核心原理PV/PVC/StorageClassPV和PVC的关系PV 描述的是持久化存储数据卷；这个 API 对象主要定义的是一个持久化存储在宿主机上的目录，比如一个 NFS 的挂载目录；通常情况下，PV 对象是由运维人员事先创建在 Kubernetes 集群里待用的。PVC 描述的是 Pod 所希望使用的持久化存储的属性，比如，Volume 存储的大
2020-07-09 18:22:00
416
原创 《深入剖析Kubernetes》总结七：Operator
权限控制Kubernetes 中所有的 API 对象，都保存在 Etcd 里;对这些 API 对象的操作，一定都是通过访问 kube-apiserver 实现的，其中一个非常重要的原因，就是需要 APIServer 来帮助你做授权工作；在 Kubernetes 项目中，负责完成授权（Authorization）工作的机制，就是 RBAC：基于角 色的访问控制（Role-Based Access Control）。RBAC：Role：角色，它其实是一组规则，定义了一组对 Kubernetes A
2020-07-07 17:32:03
987
原创 《深入剖析Kubernetes》总结六：声明式API
声明式API与编程范式想要使用Kubernetes 的 API 对象，需要编写一个对应的 YAML 文件交给 Kubernetes，而声明式API，则为kubectl apply 命令，先 kubectl create，再 replace 的操作，称为命令式配置文件操作，并不是声明式APIkubectl replace 的执行过程，是使用新的 YAML 文件中的 API 对象，替换原有的 API 对象；kubectl apply执行了一个对原有 API 对象的 PATCH 操作，类似地，kubectl
2020-07-07 15:31:53
1091
原创 《深入剖析Kubernetes》总结五：控制器与编排
在线任务编排控制器（Controller）：操作容器，比如Deployment，是k8s第一个重要的设计思想，叫作控制器模式kube-controller-manager：一系列控制器的集合$ ls -d kubernetes/pkg/controller/deployment/ job/ podautoscaler/cloud/ disruption/ namespace/replicaset/ serviceaccount/ volume/cronjob/ garbagecollector
2020-07-07 10:42:55
630
原创 《深入剖析Kubernetes》总结四：Pod解析
Pod相当于Linux操作系统的进程组Pod只是一个逻辑概念，是一组共享了某些资源的容器，它的所有容器共享的是同一个 Network Namespace，并且可以声明共享同一个 Volume；为了让Pod里的多个容器是对等关系而不是拓扑关系，Pod 的实现需要使用一个中间容器，叫作 Infra 容器，在这个 Pod 中，Infra 容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过 Join Network Namespace 的方式，与 Infra 容器关联在一起（否则容器之间互相join
2020-07-06 14:35:08
397
原创 《深入剖析Kubernetes》总结三：Kubernetes架构
Kubernetes架构一个正在运行的 Linux 容器可以被“一分为二”地看待：一组联合挂载在 /var/lib/docker/aufs/mnt 上的 rootfs，这一部分可以称为“容器镜像”（Container Image），是容器的静态视图；一个由 Namespace+Cgroups 构成的隔离环境，这一部分可以称为“容器运行时”（Container Runtime），是容器的动态视图Kubernetes关心的是“容器镜像”架构由 Master 和 Node 两种节点组成
2020-07-06 14:34:02
1689
原创 《深入剖析Kubernetes》总结二：学学容器基础
Linux容器实现手段：Linux Namespace 、Linux Cgroups ，基于 rootfs 的文件系统Mac容器，Windows容器实现手段：基于虚拟化技术Linux容器的实现手段容器其实是一种沙盒技术，能够像一个集装箱一样，把你的应用“装”起来，使应用与应用之间因为有了边界而不至于相互干扰；而被装进集装箱的应用，也可以被方便地搬来搬去；容器的本质：进程容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造出一个“边界”，Cgroups技术是用来制造约束的主要手段，N
2020-07-05 13:03:33
340
原创 《深入剖析Kubernetes》总结一：Docker的历史
Docker的盛行一开始流行的是PaaS平台，能够帮助用户大规模部署应用到集群里；用户把应用的可执行文件和启动脚本打进一个压缩包内，上传到云上的存储中，接着，云会通过调度器选择一个可以运行这个应用的虚拟 机，然后通知这个机器上的 Agent 把应用压缩包下载下来启动。内部调用操作系统的 Cgroups 和 Namespace 机制为每一个应用单独创建一个称作“沙盒”的隔离环境，然后在“沙盒”中启动这些应用进程，这样，就实现了把多个用户的应用互不干涉地在 虚拟机里批量地、自动地运行起来的目的。PaaS
2020-07-03 18:28:21
347
原创 《分布式技术原理与算法解析》总结四：分布式通信技术
分布式的本质就是多进程协作，共同完成任务，彼此之间肯定需要通信1 远程调用不同机器中运行的进程之间的相互通信，常用的是RPC，这个大家应该都懂，不说了~大家可以看看dubbo，内部就是RPC+注册中心实现的2 发布订阅RPC进程之间是直接交互的，当进程比较多时，会导致进程维护通信的复杂度非常高，且一个进程通信接口改变，与其通信的进程都会受到影响；随着业务和分布式计算规模的逐渐增大和复杂...
2020-04-01 16:39:26
415
原创 《分布式技术原理与算法解析》总结三：分布式计算技术
调度架构中的两层调度的第二层调度是由框架完成的，通常就是计算框架，比如 Hadoop、Spark 等；程序员基于这些计算框架，可以完成不同类型和规模的计算。分布式计算的本质就是在分布式环境下，多个进程协同完成一件复杂的事情；每个进程各司其职，完成自己的工作后，再交给其他进程去完成其他工作；对于没有依赖的工作，进程间是可以并行执行的。1 MapReduce核心思想：分而治之，JDK的Fo...
2020-04-01 14:02:10
962
原创 《分布式技术原理与算法解析》二-二：分布式资源管理与负载调度之分布式调度架构
从2-1中可以晓得分布式体系结构的目的是将多个服务器资源管理起来，寻找合适的服务器去执行用户任务。那什么是合适的服务器呢？衡量一个服务器是否合适会涉及很多条件或约束，比如在一些场景下，任务存在优先级，当需要执行多个任务的时候，通常需要满足优先级高的任务优先执行的条件，但在这些条件中，服务器资源能够满足用户任务对资源的诉求是必须的。而为用户任务寻找合适的服务器这个过程，在分布式领域中叫作调度；...
2020-04-01 09:46:14
687
原创 《分布式技术原理与算法解析》二-一： 分布式资源管理与负载调度之分布式体系结构
云可以把多个服务器管理起来，作为一个统一的资源提供服务服务器如何组织，就是分布式体系结构的范畴1 集中式结构概念：由一台或多台服务器组成中央服务器，系统内的所有数据都存储在中央服务器中，系统内所有的业务也均先由中央服务器处理；多个节点服务器与中央服务器连接，并将自己的信息汇报给中央服务器，由中央服务器统一进行资源和任务调度：中央服务器根据这些信息，将任务下达给节点服务器；节点服务器执...
2020-03-30 10:03:48
776
原创 《分布式技术原理与算法解析》总结二：分布式协调与同步
1 分布式互斥对于同一共享资源，要求同一时刻只能有一个程序能够访问，防止出错1.1 集中式算法引入一个协调者程序，得到一个分布式互斥算法：每个程序在需要访问临界资源时，先给协调者发送一个请求；如果当前没有程序使用这个资源，协调者直接授权请求程序访问，否则，按照FIFO规则进行排队等待；如果有程序使用完资源，则通知协调者，协调者从队列里取出排在最前面的请求，并给它发送授权消息，拿到授权...
2020-03-30 09:26:23
1301
原创 《分布式技术原理与算法解析》总结一：分布式技术总览
1 分布式体系如下图：分布式资源池化、分布式通信、分布式数据存储与管理、分布式计算四大体系的划分符合业务架构设计的一般规律：“在一定资源上，进行一定通信，通过一定计算，完成一定数据的加工和处理，从而对外提供特定的服务”而在分布式环境下，无论是资源、通信、数据还是计算，都需要去解决协同、调度、追踪高可用、部署的问题2 什么是分布式让我们从最原始的架构开始演变单机模式：穷逼模式（穷逼：...
2020-03-22 11:09:33
1083
原创 JVM底层操作总结：反射、动态代理、lambda、注解等
反射：https://www.cnblogs.com/yougewe/p/10125073.html将Java文件保存到本地硬盘后，编译Java文件，生成.class文件，然后使用JVM将字节码文件加载到内存，字节码文件在内存（方法区）中生成一个Class类表示此Java对象使用反射的时候，首先获取到Class类，这样就可以得到class文件里的所有内容，包含属性、构造方法、普通方法；属...
2020-02-15 23:23:37
444
原创 JDK序列化原理总结
参考：https://juejin.im/entry/5bf622436fb9a04a0b21cbe7JDK序列化方式中，使用ObjectInputStream#readObject进行反序列化，使用ObjectInputStream#writeObject进行序列化，反序列化稍微复杂点，朋友们可以结合文字看源码ObjectInputStream#readObject：A 判断子类是否重写了...
2020-01-16 12:09:05
894
原创 11 分库分表
雪花算法：https://www.sohu.com/a/232008315_453160单元化：https://mp.weixin.qq.com/s/pPGppiQAySBEMZja0nwxkA1 为什么需要分库分表传统的项目结构将所有子系统的数据都交给一个mysql，无法支撑这涉及到数据库性能的瓶颈：1 数据库连接数有限：默认100个，单机最大163842 表数据量：单机表数量过多...
2019-12-13 18:02:03
182
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人