gitweixin
  • 首页
  • 小程序代码
    • 资讯读书
    • 工具类
    • O2O
    • 地图定位
    • 社交
    • 行业软件
    • 电商类
    • 互联网类
    • 企业类
    • UI控件
  • 大数据开发
    • Hadoop
    • Spark
    • Hbase
    • Elasticsearch
    • Kafka
    • Flink
    • 数据仓库
    • 数据挖掘
    • flume
    • Kafka
    • Hive
    • shardingsphere
    • solr
  • 开发博客
    • Android
    • php
    • python
    • 运维
    • 技术架构
    • 数据库
  • 程序员网赚
  • bug清单
  • 量化投资
  • 在线查询工具
    • 去行号
    • 在线时间戳转换工具
    • 免费图片批量修改尺寸在线工具
    • SVG转JPG在线工具
    • SVG转PDF/Word
    • SVG转Draw.io可二次编辑格式
    • js代码混淆
    • json格式化及任意折叠展开
    • PDF常用工具

Spark Streaming多个输入流

精品微信小程序开发门户,代码全部亲测可用

  • 首页   /  
  • 作者: east
  • ( 页面56 )
Spark 12月 6,2021

Spark Streaming多个输入流

由于业务需要,一个地方部署1个Spark Streaming程序,由于业务扩展部署了多个地方,导致大数据平台的yarn资源不足了,CPU和内存经常是100%的。而且多套只是配置不同的程序,一旦有修改,维护起来也不方便。于是想到提升Spark Streaming的并行度,同时接收多个Dstream的输入。

通过网络接收数据(如Kafka、Flume、套接字等)需要将数据反序列化并存储在Spark上,如果数据接收成为系统中的瓶颈,则需要并行接收数据。主要通过提升Receiver的并发度和调整Receiver的RDD数据分区时间隔。提升Receiver的并发度:在Worker节点上对每个输入DStream创建一个Receiver并运行,以接收一个数据流。通过创建多个输入DStream并配置从数据源接收不同分区的数据流,从而实现接收多数据流。例如,一个单Kafka输入DStream接收两个主题的数据,可以分成两个Kafka的输入流,每个仅仅接收一个主题。输入DStream运行在两个Worker节点的接收器上,从而能够并行接受并行,提高整体的吞吐量。多DStream可以通过联合(union)在一起从而创建一个DStream,这样一些应用在一个输入DStream的转换操作便可以用在联合后的DStream上。

JavaDstream<string> sources1=ssc.receiverstream(new JavacustomReceiver2(ip1, port, StorageLevel.MEMORY_ONLY-2()));

JavaDStream<String> sources2 = ssc.receiverStream(new JavaCustomReceiver2(ip2, port, StorageLevel.MEMORY_ONLY-2()));
JavaDStream<String> sources3 = ssc.receiverstream(new JavaCustomreceiver2(whip, port, StorageLeve1.MEMORY_ONLY-2()));

Javadstream<string> sources3 = ssc.socketTextstream(ip3, port, storagetevel.MEMORY ONLY2())); 
JavaDStream<String> sources = sources1.union(sources2).union(sources3);
作者 east
shardingsphere 11月 28,2021

Shardingsphere 4.0.0-RC1和pagehelper分页时报错解决

项目架构使用Shardingsphere和pagehelper架构,对一个复杂sql语句,运行后报错“Must have sharding column with subquery. "

原来 PageHelper里面有个机制是,当解析的sql比较复杂的时候,会加上别名,而Sharding-jdbc执行这个带有别名的sql会报错。如果不用pageHelper,自己来分页是可以避免这个问题。但这样做比较麻烦。

解决办法是在另加一个XXX_COUNT的sql,不要让PageHelper给原始sql加上别名。 官网的做法解释如下:

增加 countSuffix count 查询后缀配置参数,该参数是针对 PageInterceptor 配置的,默认值为 _COUNT。

分页插件会优先通过当前查询的 msId + countSuffix 查找手写的分页查询。

如果存在就使用手写的 count 查询,如果不存在,仍然使用之前的方式自动创建 count 查询。

例如,如果存在下面两个查询:

<select id="selectLeftjoin" resultType="com.github.pagehelper.model.User">     select a.id,b.name,a.py from user a     left join user b on a.id = b.id     order by a.id
</select>

<select id="selectLeftjoin_COUNT" resultType="Long">
select count(distinct a.id) from user a left join user b on a.id = b.id
</select>

上面的 countSuffix 使用的默认值 _COUNT,分页插件会自动获取到 selectLeftjoin_COUNT 查询,这个查询需要自己保证结果数正确。

返回值的类型必须是resultType="Long",入参使用的和 selectLeftjoin 查询相同的参数,所以在 SQL 中要按照 selectLeftjoin 的入参来使用。

因为 selectLeftjoin_COUNT 方法是自动调用的,所以不需要在接口提供相应的方法,如果需要单独调用,也可以提供。

作者 east
技术架构 11月 28,2021

阅读开源软件源码的心得体会

互联网大厂研发的职位,很多有对源码有要求。同时,看源码最大的好处是可以开阔思维,提升架构设计能力。有些东西仅靠书本和自己思考是很难学到的,必须通过看源码,看别人如何设计,然后思考为何这样设计才能领悟到。能力的提高不在于你写了多少代码,做了多少项目,而在于给你一个业务场景时,你是否能拿出几种靠谱的解决方案,并且说出各自的优缺点。而如何才能拿出来,一来靠经验,二来靠归纳总结,而看源码可以快速增加你的经验。而不少源码十分庞大复杂,下面谈谈阅读源码心得体会。

那么如何阅读源码呢?在你看某一个框架的源码前,先去Google查找这个开源框架的官方介绍,通过资料了解该框架有几个模块,各个模块是做什么的,之间有什么联系,每个模块都有哪些核心类,在阅读源码时可以着重看这些类。或者找找是否有这方面源码解读的书,在别人探索好的路再去探索,能节省时间。

然后对哪个模块感兴趣就去写个小demo,先了解一下这个模块的具体作用,然后再debug进入看具体实现。在debug的过程中,第一遍是走马观花,简略看一下调用逻辑,都用了哪些类;第二遍需有重点地debug,看看这些类担任了架构图里的哪些功能,使用了哪些设计模式。如果第二遍有感觉了,便大致知道了整体代码的功能实现,但是对整体代码结构还不是很清晰,毕竟代码里面多个类来回调用,很容易遗忘当前断点的来处;那么你可以进行第三遍debug,这时候你最好把主要类的调用时序图以及类图结构画出来,等画好后,再对着时序图分析调用流程,就可以清楚地知道类之间的调用关系,而通过类图可以知道类的功能以及它们相互之间的依赖关系。另外,开源框架里面每个功能类或者方法一般都有注释,这些注释是一手资料,比如JUC包里的一些并发组件的注释,就已经说明了它们的设计原理和使用场景。

在阅读源码时,最好画出时序图和类图,因为人总是善忘的。如果隔一段时间你再去看之前看过的源码,虽然有些印象,但当你想去看某个模块的逻辑时,又需根据demo再从头debug了。而如果有了这俩图,就可以从这俩图里面直接找,并且看一眼时序图就知道整个模块的脉络了。

作者 east
Java 11月 25,2021

优化后台接口经验总结

开发一个后台接口不难,可能花几个小时就能跑通;而做一个好用的接口,可能要花几天时间精雕细磨。尤其是业务复杂,数据量大的,如果没有优化导致速度很慢,用户根本没耐心等。

下面谈谈优化思路:

1、串行操作改为并发操作。如果接口有串行操作,而且其中一些操作是比较耗时的,而且它们的操作没有因果关系需要等待前面的结果,那么可以把这些操作改为并发线程去操作。使用多线程遇到坑会多一些,例如线程池使用FutureTask时如果把拒绝策略设置为DiscardPolicy和DiscardOldestPolicy,并且在被拒绝的任务的Future对象上调用了无参get方法,那么调用线程会一直被阻塞。在日常开发中尽量使用带超时参数的get方法以避免线程一直阻塞。

2、对一些常用的可复用的数据库查询加上缓存。做一个系统需要经常查询点位信息,这些点位信息不会经常变,对相关的数据库查询加上缓存。如果用mybatis,可以考虑直接在xml上添加,或者利用redis进行添加。

3、数据的优化,如果单表数据过大,可以考虑进行分库分表。

4、对查询慢的语句,考虑加上相关的索引。频繁单个查询或插入,考虑是否能改为批量操作。对一些频繁查询可复用的,可以考虑一次批量查询出来并缓存起来。

5、考虑是否可以后台先计算出中间结果或最终结果,用户查询时不用从头开始计算。在接口查询计算过程,如果有频繁重复计算的,可以考虑采用备忘录算法。

作者 east
数据库 11月 23,2021

对接第三方数据库的数据遇到的坑

对接第三方的数据,根据轮询他们的数据库来对接数据。看到表设计有create_time字段,根据经验主义觉得是写入数据库的时间。于是想到对接数据方案是:如果查询时间小于当前时间,每几分钟查一次。如果查询时间大于当前时间,休眠到查询结束时间等于当前时间。后来发现一个奇怪现象:如果刚运行程序补录数据,发现没有漏数据,如果跑一段时间,追上当前时间,就出现漏数据。由于是采用jdbc框架的,不是很清楚底层,当时怀疑会不会运行久了断开数据库连接。反复修改程序还是出现这种情况,后来问第三方厂家,他们说create_time是服务接收到数据的时间,还要先写临时库,再写目标库。并且查询到第三方的数据库时间是落后标准时间的。

作者 east
Java, 运维 11月 7,2021

一次诡异系统变慢排查

给客户上线了系统(Spring Cloud、微服务,centos上运行),运行1、2年后,客户投诉系统很慢。

自己打开系统,刚开始很快,用一些时间就变慢。看前端请求的接口,是挂起状态,有的要几分钟才有结果。

检查服务器内存和CPU。这是引起系统慢常见的问题,发现这2方面改善后还是变慢,后来干脆重启服务器,依然无解。

检查磁盘坏道。之前用电脑时,如果磁盘有坏道,如果有写操作,有时也会为坏道。用centos检查坏道的命令也没发现。

检查接口代理。由于是前后端分离,用户在前端的请求,都经过第三方代理。如果直接测后台接口是很快,但通过前端访问就变慢了,于是怀疑是第三方代理搞的鬼。于是咨询第三方代理,第三方代理说他们服务的客户,都没有发现这种情况,建议我们排查网络。

检查前端。由于后来又上线几个类似的系统,前端基本一样的,没有安装新的插件。所以觉得可能性不大。

检查浏览器。网上有的说是chrome浏览器早期的bug,如果是已经请求过的接口,会复用之前的。想找不同浏览器或更新到最新chrome的。但几个一样的系统,用同样浏览器也没有变慢,也解释不通。

终极答案。经反复排查,最后发现是前端有个页面每几秒钟请求1次,而请求相关的数据库年长月久数据很多,数据库不能及时响应请求。后来根据业务需要改成几分钟请求1次,果然这个诡异问题没再出现。

作者 east
数据库 9月 4,2021

利用 Navicat 事件设计器解决多微服务对表不同的需求

在生产实践有一个项目,某个表每天新增数据几百万,甚至上千万条。项目采用多服务,有的同事的微服务只需要调用这个表几天的数据,有的同事只需要最近30天,而我这边的微服务需要查询这个表任意一段时间。

由于mysql访问数据超过上千万的数据性能下降很多,而且有的功能需要一些统计,加上原来项目是用mysql,考虑开发成本,暂时不考虑换乘nosql的方案,例如es、hbase等。于是改造成用shardingsphere每月分表。然而问题产生了,我这边访问的表名是TableA_2021_9这个的,而别的几位同事需要访问TableA。

后来想了一个解决方案,不需要他们也改造代码。方案就是保留原来的TableA,采用navicat事件进行调度,TableA只保留最近30天的数据,并每天运行定时任务,把新产生的数据复制一份到分月表。

INSERT INNORE INTO tableA_2021_10 SELECT FROM TableA WHERE START_TIME > DATE_ADD (NOW(), INTERVAL -1 DAY) AND START_TIME < NOW()
作者 east
数据库 8月 28,2021

mysql数据去重实践总结

在线上服务器,由于程序的bug,导入很多重复的数据。刚开始想到的思路是直接写SQL进行去重。例始要对login_name这个字段进行去重:

DELETE
FROM
    `oldTable`
WHERE
    login_name IN (
        SELECT
            a.login_name
        FROM
            (
                SELECT
                    login_name
                FROM
                    `oldTable`
                GROUP BY
                    login_name
                HAVING
                    count(login_name) > 1
            ) AS a
    )
AND id NOT IN (
    SELECT
        b.aa
    FROM
        (
            SELECT
                min(id) AS aa
            FROM
                `oldTable`
            GROUP BY
                login_name
            HAVING
                count(login_name) > 1
        ) AS b
);

如果mysql数量一多,用上面的方法操作效率是很低的。这时要用mysql联合索引,可以建立一个表跟oldTable结构一样的表,并对login_name建立联合索引。

alter table newTableadd unique index(login_name);

如果数择量很大,可以根据时间或主键id值进行分批插入。

INSERT IGNORE INTO newTable SELECT * FROM oldTable WHERE START_TIME >= '2021-08-20 00:00:00' AND START_TIME <'2021-08-23 00:00:00'

作者 east
数据库 8月 8,2021

Mysql线上环境遇到的坑

安装mysql很简单,但要设计好,其实并不简单。

在mysql8.0,一开始没在my.cnf设置表大小写不敏感,后面重新修改是不起效果,要重新安装。

lower_case_table_names=1

说明 0:区分大小写,1:不区分大小写

mysql安装在/usr/local目录,但这个分区大小不大,最大分区在/data,后来时间一长,用shell命令 df -h 一查看

在/dev/mapper/centos-root 磁盘100%了

作者 east
flume 7月 10,2021

Flume对接数据遇到的坑

业务是这样的:别的地方服务器通过ftp传来一些压缩包,对压缩包进行解压,然后flume进行采集发到kafka,spark Streaming进行处理。

进行解压的脚本代码如下:

#/bin/bash
end = "${dirname "$0"}"/"$1"
source = "${dirname "$0"}"/"$2"
final =  "${dirname "$0"}"/"$3"
while [2 -gt 1 ]
do
   for i in 'ls ${source}‘
   do
   if [[ ${i} != "" && ${i} != *.tmp ]]
   then
       unzip ${source}/${i} -d ${end}/
       mv -f ${source}/${i} ${final}
   fi
done
sleep 5

原本一直持续能解压文件,最近出现停止。

执行命令时,还出现提示是否覆盖。这时才明白可能是这个原因导致脚本没能顺利执行。为了不提示是否覆盖,可以加参数 -o。修改命令如下:

unzip -o ${source}/${i} -d ${end}/

作者 east
bug清单, flume 6月 13,2021

Flume pollDelay设置不正确停止采集

使用FusionInsight HD Flume从本地采集静态日志( Spooling Source )保存到Kafka,由于采集堆积太多了,flume配置参数做了一些修改。后来发现一个诡异问题:每次重启flume采集,只采集1、2个文件就停止采集了,也没报什么错误。

采用对比法排查问题,对比正常运行的flume配置,看到pollDelay跟之前的不同。才想起之前一顿三百五的操作:想加快速度。pollDelay的设置值从5000改成500。

采集方案采用的Spooling Source + Memory Channel + kfaka

Spooling Source常用配置 :

Memory Channel使用内存作为缓存区,Events存放在内存队列中。常用配置如下表所示:

Kafka Sink将数据写入到Kafka中。常用配置如下表所示:

参考配置如下:

a1.channels = c1
a1.sources = s1
a1.sinks = sink1

a1.sources.s1.type = spooldir
a1.sources.s1.channels = c1
a1.sources.s1.spoolDir = /home/ftp (填写实际的路径)
a1.sources.s1.bufferMaxLineLength = 1073741824
a1.sources.s1.pollDelay = 5000
a1.sources.s1.consumeOrder = random

a1.channels.c1.type = memory
a1.channels.c1.capacity = 30000
a1.channels.c1.tansactionCapacity = 30000

a1.sinks.sink1.channel = c1
a1.sinks.sink1.type = org.apache.kafka.kafkaSink
a1.sinks.sink1.bootstrap.servers=192.168.1.1:210007  (根据实际填写)
a1.sinks.sink1.topic = mytopic (根据实际填写)
a1.sinks.sink1.batchSize = 200
a1.sinks.sink1.producer.requiredAcks = 1



作者 east
Android, Harmony 6月 11,2021

鸿蒙Harmony和Android服务Service对比

Harmony和Android都提供了后台服务,当用户切换别的应用时,都可以使用服务来播放音乐保证不中断。

图1 鸿蒙Harmony Service Ability 生命周期
图2 Android Service的生命周期

Harmony Service Ability:

基于Service模板的Ability(以下简称“Service”)主要用于后台运行任务(如执行音乐播放、文件下载等),但不提供用户交互界面。Service可由其他应用或Ability启动,即使用户切换到其他应用,Service仍将在后台继续运行。

Service是单实例的。在一个设备上,相同的Service只会存在一个实例。如果多个Ability共用这个实例,只有当与Service绑定的所有Ability都退出后,Service才能够退出。由于Service是在主线程里执行的,因此,如果在Service里面的操作时间过长,开发者必须在Service里创建新的线程来处理(详见线程间通信),防止造成主线程阻塞,应用程序无响应。

与Page类似,Service也拥有生命周期,如图1所示。根据调用方法的不同,其生命周期有以下两种路径:

  • 启动Service该Service在其他Ability调用startAbility()时创建,然后保持运行。其他Ability通过调用stopAbility()来停止Service,Service停止后,系统会将其销毁。
  • 连接Service该Service在其他Ability调用connectAbility()时创建,客户端可通过调用disconnectAbility​()断开连接。多个客户端可以绑定到相同Service,而且当所有绑定全部取消后,系统即会销毁该Service。图1 Service生命周期

一般情况下,Service都是在后台运行的,后台Service的优先级都是比较低的,当资源不足时,系统有可能回收正在运行的后台Service。

在一些场景下(如播放音乐),用户希望应用能够一直保持运行,此时就需要使用前台Service。前台Service会始终保持正在运行的图标在系统状态栏显示。

使用前台Service并不复杂,开发者只需在Service创建的方法里,调用keepBackgroundRunning()将Service与通知绑定。调用keepBackgroundRunning()方法前需要在配置文件中声明ohos.permission.KEEP_BACKGROUND_RUNNING权限,同时还需要在配置文件中添加对应的backgroundModes参数。在onStop()方法中调用cancelBackgroundRunning​()方法可停止前台Service。

Android Service:

Service 是一种可在后台执行长时间运行操作而不提供界面的应用组件。服务可由其他应用组件启动,而且即使用户切换到其他应用,服务仍将在后台继续运行。此外,组件可通过绑定到服务与之进行交互,甚至是执行进程间通信 (IPC)。例如,服务可在后台处理网络事务、播放音乐,执行文件 I/O 或与内容提供程序进行交互。

以下是三种不同的服务类型:前台前台服务执行一些用户能注意到的操作。例如,音频应用会使用前台服务来播放音频曲目。前台服务必须显示通知。即使用户停止与应用的交互,前台服务仍会继续运行。后台后台服务执行用户不会直接注意到的操作。例如,如果应用使用某个服务来压缩其存储空间,则此服务通常是后台服务。

注意:如果您的应用面向 API 级别 26 或更高版本,当应用本身未在前台运行时,系统会对运行后台服务施加限制。在诸如此类的大多数情况下,您的应用应改为使用计划作业。绑定当应用组件通过调用 bindService() 绑定到服务时,服务即处于绑定状态。绑定服务会提供客户端-服务器接口,以便组件与服务进行交互、发送请求、接收结果,甚至是利用进程间通信 (IPC) 跨进程执行这些操作。仅当与另一个应用组件绑定时,绑定服务才会运行。多个组件可同时绑定到该服务,但全部取消绑定后,该服务即会被销毁。

虽然本文档分开概括讨论启动服务和绑定服务,但您的服务可同时以这两种方式运行,换言之,它既可以是启动服务(以无限期运行),亦支持绑定。唯一的问题在于您是否实现一组回调方法:onStartCommand()(让组件启动服务)和 onBind()(实现服务绑定)。

无论服务是处于启动状态还是绑定状态(或同时处于这两种状态),任何应用组件均可像使用 Activity 那样,通过调用 Intent 来使用服务(即使此服务来自另一应用)。不过,您可以通过清单文件将服务声明为私有服务,并阻止其他应用访问该服务。使用清单文件声明服务部分将对此做更详尽的阐述。

作者 east

上一 1 … 55 56 57 … 93 下一个

关注公众号“大模型全栈程序员”回复“小程序”获取1000个小程序打包源码。回复”chatgpt”获取免注册可用chatgpt。回复“大数据”获取多本大数据电子书

标签

AIGC AI创作 bert chatgpt github GPT-3 gpt3 GTP-3 hive mysql O2O tensorflow UI控件 不含后台 交流 共享经济 出行 图像 地图定位 外卖 多媒体 娱乐 小程序 布局 带后台完整项目 开源项目 搜索 支付 效率 教育 日历 机器学习 深度学习 物流 用户系统 电商 画图 画布(canvas) 社交 签到 联网 读书 资讯 阅读 预订

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • 解决gitlab配置Webhooks,提示 Invalid url given的问题
  • 如何在Chrome中设置启动时自动打开多个默认网页
  • spark内存溢出怎样区分是软件还是代码原因
  • MQTT完全解析和实践
  • 解决运行Selenium报错:self.driver = webdriver.Chrome(service=service) TypeError: __init__() got an unexpected keyword argument ‘service’
  • python 3.6使用mysql-connector-python报错:SyntaxError: future feature annotations is not defined
  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?

文章归档

  • 2025年12月
  • 2025年10月
  • 2025年8月
  • 2025年7月
  • 2025年6月
  • 2025年5月
  • 2025年4月
  • 2025年3月
  • 2025年2月
  • 2025年1月
  • 2024年12月
  • 2024年11月
  • 2024年10月
  • 2024年9月
  • 2024年8月
  • 2024年7月
  • 2024年6月
  • 2024年5月
  • 2024年4月
  • 2024年3月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年8月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年4月
  • 2023年3月
  • 2023年1月
  • 2022年11月
  • 2022年10月
  • 2022年9月
  • 2022年8月
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月

分类目录

  • Android (73)
  • bug清单 (79)
  • C++ (34)
  • Fuchsia (15)
  • php (4)
  • python (45)
  • sklearn (1)
  • 云计算 (20)
  • 人工智能 (61)
    • chatgpt (21)
      • 提示词 (6)
    • Keras (1)
    • Tensorflow (3)
    • 大模型 (1)
    • 智能体 (4)
    • 深度学习 (14)
  • 储能 (44)
  • 前端 (5)
  • 大数据开发 (497)
    • CDH (6)
    • datax (4)
    • doris (31)
    • Elasticsearch (15)
    • Flink (79)
    • flume (7)
    • Hadoop (19)
    • Hbase (23)
    • Hive (41)
    • Impala (2)
    • Java (71)
    • Kafka (10)
    • neo4j (5)
    • shardingsphere (6)
    • solr (5)
    • Spark (100)
    • spring (11)
    • 数据仓库 (9)
    • 数据挖掘 (7)
    • 海豚调度器 (10)
    • 运维 (39)
      • Docker (3)
  • 小游戏代码 (1)
  • 小程序代码 (139)
    • O2O (16)
    • UI控件 (5)
    • 互联网类 (23)
    • 企业类 (6)
    • 地图定位 (9)
    • 多媒体 (6)
    • 工具类 (25)
    • 电商类 (22)
    • 社交 (7)
    • 行业软件 (7)
    • 资讯读书 (11)
  • 嵌入式 (71)
    • autosar (63)
    • RTOS (1)
    • 总线 (1)
  • 开发博客 (16)
    • Harmony (9)
  • 技术架构 (6)
  • 数据库 (32)
    • mongodb (1)
    • mysql (13)
    • pgsql (2)
    • redis (1)
    • tdengine (4)
  • 未分类 (8)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

All Rights Reserved by Gitweixin.本站收集网友上传代码, 如有侵犯版权,请发邮件联系yiyuyos@gmail.com删除.